@tunnckoCore Is this something you are open to?

To clarify, we'll be using this library in auto-release (soon to be renamed to just auto). 😊

I don't see how this can be a problem when we have the module field. And that's absolutely intentional. Both Rollup and Webpack understands it and uses it if it is found.

In the Webpack case, as far as I know, you may need to put 'module' before 'main'.

I'm moving soon everything (most of my packages) to the https://github.com/tunnckoCore/monorepo, so in anyway I'll have Babel 7 + TypeScript pipeline. But still will follow that pattern main: index.js (esm bridge) for cjs and module: dist/index.js (compiled code)

GitHub

tunnckoCore/monorepo

Mono-repo including scoped and non-scoped packages, independently versioned. Managed by @lerna and @yarnpkg. Using Jest, @eslint, @prettier and TypeScript through @babel 7. Automatic dependencies u...

oops, accidentally clicked "Comment and close", sorry

So, what's the problem? I really liked that pattern.

Sweet. That's basically what I'm looking for.

The problem is I'm in node and import/export is still experimental in node an hidden under a flag. So not many user are using it.

My problem with esm is that it increases the bundle size of this tiny module considerably.

https://packagephobia.now.sh/result?p=parse-commit-message (71.7kB install for node)
https://bundlephobia.com/result?p=parse-commit-message@3.2.3 (5.3kb install size for modules supporting platforms)

Package Phobia

Find the cost of installing a node dependency

parse-commit-message@3.2.3 ❘ BundlePhobia

Find the performance impact of adding a npm package to your bundle.

Some minifcation goes on with the second number, but it's still quite a big difference.

(I could be wrong though feel free to correct me)

The esm is behind the Node's flag anyway.

I understand, but still why you are looking so hard on bundle size when auto isn't an app (or I'm wrong?) and it's users won't care much. Also, 50-60kb are mostly nothing compared to what most of us have as devDependency - at least eslint + codestyle config (eslint + airbnb is around 9k packages) .

Don't get me wrong, I was on that team (no bundling, transpiling or etc stuff, just 2-3 devDeps for linting and testing, 100% coverage and CJS) until recently. Before few months started migrating to esm loader and that current pattern here. And all that was because I want future proof packages. If I never touch them they still will be working (one day even in the browsers natively, loading directly from npm? haha, why not), because they are using pure ES Modules and features existing in browsers and node since 8.10. And not forget that they will be available through unpkg.com both the CJS and ESM, so...

Just recently starting to push much harder to setup huge monorepo with all the cool things. And actually I always was thinking about something similar to monorepo, even before they existed. And I really feel good that finally everything is almost ready. The only problem with monorepos is that they mess with automatic versioning and releasing and publishing on CI.

Btw, don't know still what exactly is auto-release, but I have a lot of works around that thing - most of them are at @tunnckoCoreLabs org and this one @tunnckocore/release-cli which should move it to the @standard-release which I started before month or two.

auto works for more around PR labels. I've found this is a better model for outside contribution. Strict commits can be a hinderance in many cases.

A user wants a plugin to parse the conventional commit messages though so we've settled on this package.

It creates github releases as well as:

• maintains a changelog
• publishes releases
• pluggable for multiple platforms
• a few other tools for PR interaction are bundled int

The only problem with monorepos is that they mess with automatic versioning and releasing and publishing on CI.

Oh and auto works out of the box with monorepos 😎

Also, 50-60kb are mostly nothing compared to what most of us have as devDependency.

True, but there's a reason we got there. 😉 Why make the same mistake with a modern tool?

Why make the same mistake with a modern tool?

I also thought about making it peerDependency from the beginning and say to users to install esm if they want CJS support. Btw, there will be esm package in user's node_modules for sure, so he won't feel the problem.
And I don't think it can be mistake since it will be native soon and everything will work. The only thing will be to remove the esm as a dependency. I think it's a lot better approach to have it by default and will make more users happy than using it as peerDep for other users that care about size.

True, but there's a reason we got there.

Interesting, can I ask what? If you plan to somehow bundling it, they point to use the module.

And I don't think it can be mistake since it will be native soon and everything will work.

import/export has been under the experimental flag since node 8? It's been on the horizon for a while, so I'm not all that sure adoption will be here soon.

make more users happy than using it as peerDep for other users that care about size.

I agree that it should be a peer deep for your non-node users.

True, but there's a reason we got there.

What I meant by this was more of a response to "mostly nothing compared to what most of us have as devDependency". The only reason tools like eslint are so big is because they never cared about code size from the beginning. I know users don't want to download 5mb of javascript to create a release. 50-60kb of cruft is a lot when you are trying to keep lean. Repeat it a few times and you are adding megabytes

If you plan to somehow bundling it, they point to use the module.

hmm ive seen other packages contradict this.

(削除) Just to round back up on this, it seems that when running npx auto --help will fail due in part to this packages import of esm. I created an issue there at intuit/auto#244. I wonder if npx and esm just fundamentally clash. I've been looking for reported issues but I haven't found a lot. (削除ここまで)

(削除) If you want to go the bundling route I generally tend to rely on developit/microbundle for all my library bundling needs. One dependency, one bundle, little-to-no config. (削除ここまで)

(削除) In the meantime I'll continue to search for potential solutions. (削除ここまで)

Edit: Evidently my debugging abililties go out the window at night. Please ignore. >_>

@zephraph Hmm, shouldn't Auto be using v4 of parse-commit-message (found here)? That version comes with a CommonJS bundle, I think.

Oh, yeah, my bad. I traced it down to index.js line 4... I thought that was this repo, but the statement on the other repo matches what I was seeing (Error: Cannot find module './dist/cjs').

Agree. Dont have much to say.

So, is this really an error with the beta-x tag?

I tried it and dont have this error. We shouldnt have err bbecause it now has cjs bundle on the main and esm on the module field.