Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build and testing for browsers? #11

Open
arikon opened this issue Feb 20, 2014 · 10 comments
Open

Build and testing for browsers? #11

arikon opened this issue Feb 20, 2014 · 10 comments

Comments

@arikon
Copy link

arikon commented Feb 20, 2014

Do you plan to make a build for browsers and test must.js in browsers?

It is a show stopper for us to use it for our UI libraries.

@moll
Copy link
Owner

moll commented Mar 5, 2014

Hey, Sergey! Sorry for the belated response.

YES! I've so far been just using it with Browserify, but I'll cook an independent version up for you guys! Thanks for nudging! :)

@verkholantsev
Copy link

Check out this pull-request: #13

@lindem
Copy link

lindem commented Apr 22, 2014

I'd also like to see a script-taggable thing to use anywhere, if you get around to it.

@kofifus
Copy link

kofifus commented Aug 3, 2017

+1

@moll
Copy link
Owner

moll commented Aug 31, 2017

Hey, fellows! After a good 3 years of pondering, I've pondered up a question of how are you fellows running your unit tests in browsers? :) Don't the popular test runners these days use Browserify or something equivalent internally that makes using CommonJS libs (like Must.js is) transparent? Where do <script src> tags come into play?

@lindem
Copy link

lindem commented Aug 31, 2017

Having become someone who's being paid for developing web applications with Ember some time ago, I just use QUnit, since that is the (supported) default with Ember.

To the other question: Not everyone wants node.js in their build chain (I've encountered people not even having a build chain), even nowadays.

I am not sure saying "Yeah well use a build step to make it transparent" is going to accomplish anything; jobs where a java shop just wants one or two pages with oldskool js are still plentiful. People still build "unit test pages".

We did discuss some of this earlier I believe. Not having a script-tag-version made this library unacceptable twice to my employers and once I built it myself and that version was accepted (if you can even remember my PR back then).

@moll
Copy link
Owner

moll commented Aug 31, 2017

Okay, fair enough. Do you reckon building one and publicizing it under the GitHub Releases page when releases are made would suffice? There's probably not point in putting it up on NPM I reckon as then we're back to the "needs a build chain" (even if just for getting a module down from NPM). 8)

@moll
Copy link
Owner

moll commented Aug 31, 2017

And, oh yeah, thanks for reminding #15! :)

@lindem
Copy link

lindem commented Aug 31, 2017

If you are willing to make an effort: You can't do more than making one, having it be easy to find, and see if people are downloading it or not. I remember wishing it to be more well-known; I really liked must.js back then.

More exposure wouldn't hurt, but that wasn't what you were asking. And of course there is the possibility that my experiences are not the norm and that I run into weird people all the time and there really is no need or case for it. I can't say.

@kofifus
Copy link

kofifus commented Sep 1, 2017

Personally I want to use must in environments which don't use node or browserify. I'm talking about plain html+js or htmls with js in script tags, browser extensions etc ... so browser version will be very useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants