Skip to content
This repository has been archived by the owner on Mar 27, 2020. It is now read-only.

add module and jsnext:main to all tasks #26

Closed
tunnckoCore opened this issue Dec 31, 2016 · 7 comments
Closed

add module and jsnext:main to all tasks #26

tunnckoCore opened this issue Dec 31, 2016 · 7 comments

Comments

@tunnckoCore
Copy link

For more robust loading and bundling.

edit: I mean, adding module and jsnext:main fields in the package.json file.

and a bit off-topic: tests are very big need. I don't think simple tests like this are enough. :) See start-rollup tests for real example of 100% coverage :)

@tunnckoCore
Copy link
Author

tunnckoCore commented Dec 31, 2016

Actually, about module and jsnext:main is/was big discussion here and there. So I just noticed that Rich Harris updated Rollup's wiki pages and it seems module is the way to go.

They're the same thing, except that module is more likely to become standardised.

ref: https://github.com/rollup/rollup/wiki/pkg.module

@tunnckoCore
Copy link
Author

tunnckoCore commented Dec 31, 2016

And in some cases, using rollup would be good.

I can start PRs. Won't be so big deal and hard job. Also i'm stuck because of these transpileings, presets, shits, rollups, webpacks, browserifies and etc. It's soooooo huge, that I can't make good flow. Because in same time I don't want huge devDeps, huge and hard configs, repo root poluted and etc. I want flexibility and believe that start could give me that if we move things here and there.

After ~15-20 hours last night, I finally end up with one preset that I intentionally wanted to be in one bundle as much as possible to low the download/install time in development. But anyway, in the end i got 4M bundle with bugs (in build step there were not errors, it is successful, haha. But because the tons of deps and mixed exports, multiple packages includes same packages, but different versions; some deps are already ES2015, others are CJS and etc.. it's absolutely mess ;d).

(damn, I should start a blog, i have tons to write, haha...)

But yea, I'm a bit strange. But yea, I believe in Start + Rollup + Buble. Not Webpack2, not webpack2 + babel and other shits, not browserify, not browserify with babelify, or browserify with rollupify + buble, or browserify + bubleify... No, tried everything and it sucks. The absolute combo and future is Rollup + Buble (or if one need more sugars can set rollup-plugin-babel instead of the rollup-plugin-buble). Buble, because I don't use so much currently and always try to stay to standards with no extra stuff. Buble, because there is target option, you set it and don't mind, about what preset to use, what combination of transforms, what version of node supports what and what you don't need, no thinking for the new babel-preset-env or whatever it is called. Rollup bundles itself, buble bundles itself - it's just awesome and small to install.

Anyway.. it's completely offtopic. Just sharing my headaches for last month - I hate them, and I worked and sleeped very well very long time without them. But I liked few things, so want to use them and it's completely okey now as node < 4 is almost dead (ofc, it is still alive in production). So I believe I can have just start-simple-cli + my own preset which will be bundled as much as possible to have lower deps and lower install times, but in same time to provide great dev flow, clean package json, clean repo root, fast installs, es2015 and cjs bundles.

So in short: I can't continue my work in any viewpoint, until i finish the workflow and scaffolding. So I can invest as much time as it is needed. I can be here every day from tomorrow to move this project forward as much as possible. 😍

@deepsweet
Copy link
Owner

add module and jsnext:main to all tasks

I have no real experience with Rollup, but this sounds ok for me. I have just to finish all the current refactorings (it's only 2 or 3 tasks left) and then will look into this.

They're the same thing, except that module is more likely to become standardised.

I can just believe you at this point :)

tests are very big need. I don't think simple tests like this are enough

I know :( if only I have time... I'm a big fan of 100% coverage, and as you can see we already have "something", a primitive stubs just to have at least some tests. all the tasks must be covered with real tests for sure.

damn, I should start a blog, i have tons to write, haha...

DO THAT! really :)

But yea, I believe in Start + Rollup + Buble. Not Webpack2, not webpack2 + babel and other shits, not browserify, not browserify with babelify, or browserify with rollupify + buble, or browserify + bubleify...

I have a lot of experience with Webpack and one project done with Browserify. All the rest tools like Rollup, JSPM, SystemJS, Buble and etc sounds more like alternative universe for me, but I'm sure these tools are cool and have some real advantages. and I can feel some of your pain for sure.

to move this project forward as much as possible

and I really need a lot of help!

@deepsweet
Copy link
Owner

btw why Start and its tasks may need to be used by bundlers like Rollup? I'm a little afraid of this:

If you're using things like arrow functions and classes (or more exotic features like decorators and object spread), you should transpile them if you want your library to work in environments that don't support those features.

so we need to put into build/ same files like we have now but with no import/export transpiled?

@tunnckoCore
Copy link
Author

tunnckoCore commented Jan 2, 2017

I believe we should integrate rollup into all tasks. And config for rollup could be nothing more than that

'use strict'

import buble from 'rollup-plugin-buble'

export default {
  entry: 'src/index.js',
  targets: [
    { dest: 'lib/index.es6.js', format: 'es' },
    { dest: 'lib/index.js', format: 'cjs' }
  ],
  plugins: [buble({ target: { node: '4' } })]
}

and in package.json

  "jsnext:main": "lib/index.es6.js",
  "module": "lib/index.es6.js",
  "main": "lib/index.js",

So package would expose both commonjs and es2015 module (which is like what is currently in the repos).

This is most simple config and currently both Rollup and Webpack requires shitty config files in the root when everything and such simple configs could be in package.json.

So btw, i'm now building https://github.com/rolldown (https://github.com/tunnckoCore/rolldown) which will do exactly this - simplifying the configuration and allowing you for presets.

why Start and its tasks may need to be used by bundlers like Rollup?

Bundling the tasks with it, will allow us to make bundled presets - meaning that it will have lower deps and better install times. As I said, I wanna have as small as possible install times.

And just to be more clear. Rollup by default resolves just the local files and makes one single file bundle, it not includes the external dependencies in that bundle.

look how the lib/index.js (which is the package.json's main field) of rolldown starts

'use strict';

function _interopDefault (ex) { return (ex && (typeof ex === 'object') && 'default' in ex) ? ex['default'] : ex; }

var r = _interopDefault(require('rollup'));
var extend = _interopDefault(require('extend-shallow'));
var loadPkg = _interopDefault(require('load-pkg'));

// ...
// all code of all local files

Then when we are building presets, we can try to optimize more (what I tried before few days) with rollup-plugin-node-resolve and the final bundle for the preset will include both local and external dependencies - the whole stuff. Of course it cant include everything, because somewhere in the deep deep deps things goes wild. But all this will low the install time of that preset. Currently it's not possible to do that, because all tasks expose cjs which Rollup can't understand. Actually there is a plugin that convert cjs to es2015 modules, but it doesn't do the tree shaking on such modules. But that isn't the only problem, the another problem is that this plugin can't convert dynamic requires (which we see in some tasks) to es2015 modules.

I'm a little afraid of this:

That's the coolest thing. Rollup does nothing more than that to bundle multiple files. But allows you to includes plugins to transform the rest code. Because of this it is perfect with Buble, which in turn if is used standalone (not as rollup plugin) will throw an error that it not understands es2015 modules. But if is used with above config is is very cool - rollup bundles all files, buble transforms the rest code.

I know that forcing you to move to rollup + buble is not cool. But it's a lot simpler, better and smaller - the cool thing of buble is that you just define target and don't think for presets for browsers, for what babel transforms to include and etc - and both rollup and buble are really small and almost no deps, so very good install times. And soon when I finish rolldown there won't be need for config files, would be enough to define even more simpler config in package.json then above.

@deepsweet
Copy link
Owner

closed as not relevant anymore, see master branch.

@tunnckoCore
Copy link
Author

tunnckoCore commented Apr 15, 2018

Yea, it seems awesome now! Babel + TypeScript. <3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants