We "fixed" it for ourselves by adding something like this to the webpack config:

alias['json-truncate'] = path.resolve(
    __dirname,
    'node_modules/json-truncate/dist/json-truncate.js'
);

But it would be nice if we could avoid doing it. :)

Actually, adding the following was even better / more generic:

'json-truncate': 'json-truncate/dist/json-truncate.js'

Thanks for this lib btw 👌

@ZeeCoder do you have some recommendations on what might work for your scenario? Maybe a PR that I could reference to see what you had in mind?

I would just remove everything in index apart from pulling in the dist/ build.
But that might not work for reasons I'm not aware of, I'm not sure why babel-register is there in the first place.

Essentially that's why I added the extra resolution field to avoid that require statement altogether.

@ZeeCoder Its there for local testing.I believe it to be only a dev dependency so shouldn't be used. Since you are using the browser CDN, I think we would need to either checkin the dist file (which I'm not a fan of), we write this library with browser compatibility in mind (I "may" be a fan of this, not sure...) or you load it with a babel-register client-side somehow to interpret some of the es2015 syntax.

I only have light opinions at the moment but would be interested in what you could come up with. You are using this library outside of its original intent so since you are pioneering here I'd be interested in what your thoughts are.

I'm not using a CDN at all, sorry for the misunderstanding 😅

I'm using webpack to compile to the browser.

So when I do that, naturally the index.js gets pulled in, with the "dev dependency", which is babel-register, and all that gets bundled in.

Your lib I think is already quite browser-compatible, if node_modules are compiled as well.
(Which newer setups do, like CRA with Babel 7, as well as us in-house.)

I would simply recommend adding a watch mode for the project for development, so then the index.js file could be simplified to simply require the dist file.

@ZeeCoder I think that babel-register only gets loaded if the dist/index.js file doesn't exist, at least thats what I'm seeing. You seeing something else?

It works differently when you bundle things with webpack instead of running this through Node.

webpack won't ignore that require, but instead try to bundle it with the rest of the code, as it's not smart enough to know it won't execute.

@mrsteele okay so I did some further digging in what you might be using babel here for.
I've added preset-env instead of preset-es2015, with which I could target certain node versions.

Anything above Node v6 results in an identical build where Babel doesn't do anything, apart from changing the es6 default export to module.exports.

To me it seems like having babel at all is unnecessary, especially considering that it only complicates development. (Hence why there's babel-register to make it easier, instead of adding a watch mode.)

So my new recommendation is then to drop Babel, and simply use module.exports for the single export this library has.

Pros:

• Simplifies the build (as there'd be no build): which means no need for babel-eslint either or any of the extra deps
• Simplifies the file structure: no need for separate index.js, src, dist.
• No actual breaking changes in terms of Node support (that is assuming you're not supporting Node4, which I think you shouldn't as even v8 will enter EOL by the 31th this year)
• You could list the module as isomorphic without any extra efforts! 🎉

Cons:

• Not being able ot use that nice default export ... syntax I guess 😅

Keen on your thoughts @mrsteele ! 🙌

(I'm more than happy to produce an MR if you'd like. 👌 )

@ZeeCoder Yeah go ahead with the PR, i'd be interested to see this finalized!

@mrsteele just pushed some further updates to the PR.