Build unminified version to dist with sourcemaps about informed HOT 10 CLOSED

Ye, it's important not to ship unused code.

Looking at Vue, React, Angular, RxJS, Lodash - they all publish unminified code, and it's unusual for modern projects not to use at least one of these libraries / frameworks. Lodash doesn't even publish minified code; they leave it up to the dev / team entirely: lodash/lodash#1227.

An unminified version would:

• add a few extra kilobytes to the npm eco-system
• have no adverse effects on the library itself
• open the possibility of exporting commonjs modules that can be imported independently from each other (perhaps a user needs only Form and Text and nothing else) and reduce bundle size
• make debugging easier for end users, and thusly
• make finding issues and contributing to informed easier

eh?

EDIT: problems have arisen a few times because I've forgotten props / components etc. - what could take seconds takes minutes to diagnose. Ideally there would be no issues during dev, but we don't know what our users don't know.

from informed.

Just checkout the source code and npm link. Two commands and u are good

from informed.

In CI you'd have to explicitly configure an additional step to handle the npm link on dev. On a team of devs having everyone npm link a specific package in order to debug isn't scalable either. Then there's the issue of managing versions in a project's package.json in tandem with what has been checked out in the linked package.

Additionally, package.json references dist/index.js. Every time there are changes or fixes an end user would have to remember to fetch master, and rebuild. On a team different versions of the linked module would create unnecessary cognitive overhead and development-time issues.

Is there something specific you are adverse to for building an unminified version into dist?

from informed.

So there is... you typically want to keep published npm packages small. Adding the unminified code is not typical for libraries. Thats what github is for. Problems should arise very infrequently and when they do thats when you can pull the source npm link and debug.. you should not have multiple team members using a non stable release that you have locally.

from informed.

Hmm you may be convincing me.. i am going to do a little research and get back to you

from informed.

So i kind of like what react does

if (process.env.NODE_ENV === 'production') {
  module.exports = require('./cjs/react.production.min.js');
} else {
  module.exports = require('./cjs/react.development.js');
}

from informed.

Ye, as far as I can tell that's primarily to show errors and warnings for developers at dev-time, with the production version stripping errors out.

They're doing some of the heavy lifting with minifying the production styles for you, too, but with how prolific Webpack, Parcel, RollUp etc. are in workflows it's only really important for CDNs that there's a minified version of a library, as everyone's minifying for production through configs (or at least they should be).

Where are you thinking of making use of NODE_ENV?

from informed.

The developer uses NODE_ENV.. in react that code above lives in the index.js file.

from informed.

In the mean time i just released a version that has the source maps.

from informed.

Source maps are there and so is an esm directory

from informed.