Tape: Browser build

[lastmjs]

Is there a browser build available for tape? It seems to only be ready to use out of the box in Node. I would like to be able to use tape in the browser without any kind of build step of my own.

[ljharb]

None is needed; browserify (and webpack or equivalents) already know how to bundle it up to work in the browser.

A build step is required for modern web dev, and will be for the foreseeable future; there's just no way around that.

[johnhenry]

I agree with @ljharb in that a browser build is not specifically _needed_, but it would be nice to be able to work with a library that can be imported into modern browsers without needing a build step. I think it would be super useful to do this:

test.html

...
<script >
import test from "<some cdn url>/tape.js";
import md5 from"<some cdn url>/md5.js";
test("test hash", ({end, equal}) => {
  equal(md5(""), "d41d8cd98f00b204e9800998ecf8427e");
  end();
});
</script>
...

Perhaps it worth looking into adding rollup.js?

[ljharb]

No thanks.

https://wzrd.in may help if for some strange reason you don't have a build process.

[backspaces]

I have a minimal build step, but I do use Rollup to convert it into a single ESM, an IIFE, and a CJS.

But even so, I definitely agree with @johnhenry and indeed, all my repos have a docs/ dir thus are gh-pages, and I export all my dist/ dir. I.e. every repo is its own cdn.

So shouldn't tape be Rollup'ed into multiple formats?

[ljharb]

I don't see the point in anyone doing that. A build process is an app-level concern, not a library-level concern.

[bennypowers]

If the attitude of tape maintainers is "you shouldn't be able to run our code in the browser - we require you to use tooling", then please at least remove the false advertising "and browsers" from the package description. Perhaps change it to "and browsers if and only if you are willing to transpile with external tools".

Even if that tooling is popular, that shouldn't make it necessary.

[bennypowers]

@ljharb since build step is an app-level concern, and since it is an optional step for app development, libraries should ship code that just runs

therefore, tape should either ship code that runs in the browser, or it should rebrand itself as node-only.

[backspaces]

This seems reasonable to me: make the docs, and your intentions for the future, clear.

And please understand that many of us do not need tooling during development .. only at test/commit/publish time: bundling, minification etc.

I suppose we could all to an "install" build step that converts your repo into modern JS when installing/upgrading it in our repos. Then it would not be in our dev work. I think a Rollup using rollup-plugin-commonjs would work. See a rollup config I use for a charting library below.

Possibly tape could document a simple Rollup (like this if it works for tape), thus making easier for devs. Oh, and btw: Puppeteer has made browser use more common for testing, where tape is king!

import commonjs from 'rollup-plugin-commonjs'
import nodeResolve from 'rollup-plugin-node-resolve'
export default {
    input: './node_modules/chart.js/dist/Chart.js',
    output: {
        file: 'chart.esm.js',
        format: 'esm',
    },
    plugins: [
        nodeResolve(),
        commonjs(),
    ],
}

[ljharb]

The tooling is necessary, whether it’s popular or not.

Separately, I’d suggest not developing with a radically different toolchain than in production - if you use a bundler in production, you should be using one in development if you want to truly be able to test out your site.

Additionally, rigorous browser testing requires testing older versions - tape, afaik, is the sole remaining test framework that supports older browsers.

This issue has long since been answered; closing.

[bennypowers]

The tooling is necessary, whether it’s popular or not.

How can I be more clear about this? That statement of yours, that tooling is necessary, is not true. This whole issue is in fact saying "some of us developers would prefer no to use tooling, please support our use case".

If you don't want to do that, for whatever reason, that's totally cool, but please don't insult our intelligence by just flat our contradicting our own lived experience.

[ljharb]

Let me rephrase: if you want to use every available JS package, the tooling is necessary. That a number of packages continue to enable legacy workflows such that you can carve out a working subset doesn’t change that.

[bennypowers]

@ljharb Thank you for responding 😄

legacy workflows

Perhaps this is a different issue than OP's, but I'm talking about evergreen browsers. There's no fundamental or intrinsic reason this shouldn't work:

<script type="module">
  import f from './f.js';
  import test from '/node_modules/tape/index.js';
  test('f fs', function testF(t) {
    t.equals(f(), 'f');
    t.end()
  })
</script>

There's nothing inherent to tape that makes that impossible, or even undesirable, and its the kind of thing that many of us do with other libraries all the time.

Yes, older browsers will need a build, but we already knew that.

[ljharb]

Sure there is - that implies you have all of node_modules exposed publicly to the web, which would be a terrifically bad security hole. If it doesn’t, then you had to configure your app in some kind of custom way.

Also, for that to work, tape would have to be ESM - not a “browser build”, but a Module. Since node hasn’t shipped ESM yet, it would be a short-sighted mistake to ship ESM now - but once it has, tape will certainly ship mjs files alongside its JS files.

Regardless, native ESM is slow in browsers, so i wouldn’t recommend using it yet.

[bennypowers]

configure your app in some kind of custom way

I'm advocating for this library to leave those kinds of decisions to app developers by releasing standard modules. It's not tape's or any other library's job to make decisions about how i architect an app, right?

[ljharb]

That’s the point - standard modules dont leave those decisions to app developers. Forcing a bundler does.

[bennypowers]

I think we're talking about tape's own dependencies

In which case you could roll those up into a lib module and have tape import from it with relative urls

then my build step, as an app developer, becomes

npm i tape
cp -r node_modules/tape assets/tape

<script type="module">
  import test from './assets/tape/tape.js';
  test(...)
</script>

i could even skip the cp step if i wanted, I suppose.

[bennypowers]

Just to be clear, if you, as pkg maintainer, have any reasons for not wanting to do that, I think that's ok.

I just think you should in that case change the description from "support browsers" to "supports bundlers" or something.

[ljharb]

"Supports browsers" means "via a bundler". I'm sorry if you have a different definition for that.