-
-
Notifications
You must be signed in to change notification settings - Fork 305
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
Using in the browser #333
Comments
Use browserify. Without more qualifications, this sounds to me like "I don't want to use a tool that will solve my problem." and I can't help you with that. |
Unfortunately Browserify isn't my thing. Too bad, because Tape is awesome! Thanks for the quick response. |
@treshugart the entire JS/npm ecosystem requires browserify, webpack, or something similar - modern JS development can't be done without them. Good luck! |
The responses here seem defensive, or condescending, but maybe text can be hard. I apologise; my question was genuine. I ask because the docs say "tap-producing test harness for node and browsers" but when you load the bundle in the browser it throws an error because it can't find Node's I'm using Webpack, so maybe I can just add |
@treshugart text is hard :-) I also apologize for coming off defensive and/or condescending. Webpack should work just fine. As you can see, there's only one place where If you configure |
Front-end development is crazytown, that's all I want to say after reading this thread. I do full-stack JS and my preference is to stay as far away from Webpack and Browserify as possible. I have found that I can transpile React with TypeScript, and TypeScript can also transpile into AMD syntax, so I use RequireJS. You don't need Webpack and Browserify for "modern" web dev, that's a damn lie :) However, @treshugart I am not sure how you were expecting to get Tape tests into the browser? What were you expecting? Perhaps look at Mocha for answers. @ljharb @substack there is one other answer. NPM authors that write isomorphic projects can provide a single-file distribution of their project, browser-ready and everything. There are many projects that do this. Why shant Tape? Shant it? This saves other developers time. This whole thing of expecting people to use NPM to do front-end development is a bit hardheaded IMO. The majority of NPM projects that are designed to be used in the browser should have a single-file distribution that is browser-ready.* If this could be standardized to Here's a good rule of thumb: if you the project creator are not able to pre-bundle your project into a distribution ready for browser consumption, don't expect others to not come with questions like @treshugart's question here. *The only caveat to this is if the project is so large that it needs to broken up into chunks, and in that case, I don't have an answer. |
In case if someone will look for an answer: add the next to your webpack config
|
That is simply not true. It may be a popular opinion, but its founded on FUD about the capabilities of the web platform. I'd rather use tape for my browser testing than Mocha, but if I can't do that because the attitude of the tape developers is "everyone else is using complicated but strictly unnecessary tooling so you should to" then I'll have to forgo this awesome lib for now. |
@bennypowers it’s quite true, I’m afraid. You can certainly use tape via a simple build process, just like the majority of the JS packages out there. Its unfortunate if that means you choose not to use tape, but given that it’s the sole remaining test framework that works on older browsers (including mocha), you might be causing more problems for yourself than you think. |
Maybe I missed something. Your claim was that the entire JS/npm ecosystem requires users to use a bundler. Yet, there are many libraries on npm that don't. I've built whole apps with them. In fact there are entire communities of developers who try as much as possible not to use any tooling at all asides from the browser (and I guess a keyboard) So, it must not be true that the entire js/npm ecosystem requires a bundler. So say you don't want to directly support the browser - that's fine. I'm just advocating for a little truth in advertising here. |
There are certainly a minority of libraries that don’t; but the aggregate does. We do directly support the browser - via a bundler. Native ESM would require using URLs, which are application-specific, and thus require tooling to customize. Using UMDs and dropping stuff in the global namespace is an archaic bad practice, and makes files larger for all users just to appease the “i don’t even own a tv” extremists who insist on avoiding tooling (yet who still use a minifier, i suspect). |
unless they are relative URLs, so that's not a concern
Preach! how about esm with relative urls? |
node hasn’t shipped ESM yet, and even relative URLs implies either custom app config, or that all of node_modules is exposed to the web, which would be a horrifically bad security hole. |
(Separately, this issue is about a browser build, not an ESM build - but that won’t come prior to node shipping it, and will come the instant node does) |
Tape seems to use some node built-ins but obviously that's not available to the browser. How does one go about this if they can't / don't want to use Browserify?
The text was updated successfully, but these errors were encountered: