Tape: Using in the browser

[treshugart]

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?

[substack]

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]

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

[ljharb]

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

[treshugart]

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]

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

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]

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

node: {
  fs: 'empty'
},

[bennypowers]

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]

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

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]

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]

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]

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]

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