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

Using in the browser #333

Closed
treshugart opened this issue Nov 24, 2016 · 14 comments
Closed

Using in the browser #333

treshugart opened this issue Nov 24, 2016 · 14 comments

Comments

@treshugart
Copy link

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?

@ghost
Copy link

ghost commented Nov 24, 2016

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.

@treshugart
Copy link
Author

Unfortunately Browserify isn't my thing. Too bad, because Tape is awesome! Thanks for the quick response.

@ljharb
Copy link
Collaborator

ljharb commented Nov 25, 2016

@treshugart the entire JS/npm ecosystem requires browserify, webpack, or something similar - modern JS development can't be done without them. Good luck!

@treshugart
Copy link
Author

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 fs module.

I'm using Webpack, so maybe I can just add { target: 'node' } or something like that? I can't test it at the moment and even if it works, it still leaves me wondering if there's any other caveats.

@ljharb
Copy link
Collaborator

ljharb commented Nov 25, 2016

@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 fs is required, and it's used here - as long as fs exists and fs.writeSync is falsy, it will work fine in the browser. As you may be able to see in the browserify bundle, browserify shims fs by default as an empty module (id 1 in the output; grep for {1:[ to find the start of the module) - which thus results in an empty object.

If you configure webpack to replace fs with an empty object, then anything that relies on browserify should work fine, including tape.

@ORESoftware
Copy link

ORESoftware commented Nov 25, 2016

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 dist/bundle.js or whatever, we could really go places. Otherwise if you don't create a clear pathway to bundling a project for browser consumption, you put too much onus on web devs that just want to get code in the air. Be responsible for your own projects.

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.

@sergej-s
Copy link

sergej-s commented Jan 17, 2017

In case if someone will look for an answer: add the next to your webpack config

node: {
  fs: 'empty'
},

@bennypowers
Copy link

bennypowers commented Dec 11, 2018

the entire JS/npm ecosystem requires browserify, webpack, or something similar - modern JS development can't be done without them. Good luck!

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.

@ljharb
Copy link
Collaborator

ljharb commented Dec 11, 2018

@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.

@bennypowers
Copy link

bennypowers commented Dec 11, 2018

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 the argument that tape doesn't need to support those use cases because no one does doesn't obtain.

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.

@ljharb
Copy link
Collaborator

ljharb commented Dec 11, 2018

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).

@bennypowers
Copy link

URLs, which are application-specific

unless they are relative URLs, so that's not a concern

UMDs and dropping stuff in the global namespace is an archaic bad practice

Preach!

how about esm with relative urls?

@ljharb
Copy link
Collaborator

ljharb commented Dec 11, 2018

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.

@ljharb
Copy link
Collaborator

ljharb commented Dec 11, 2018

(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)

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