Any plans in supporting real ES and ES2015 format?

[ghost]

Any plans in supporting real ES and ES2015 format? I'm used too Rollup and was looking for an alternative solution, but confused about the bundling.

For me a ES or ES2015 format looks like this:

import a from './b';
export default a;

With paeckchen it looks like this (I tried to change the flags in the CLI, but same result):

var __paeckchen_cache__ = [];
function __paeckchen_require__(index) {
    if (!(index in __paeckchen_cache__)) {
        __paeckchen_cache__[index] = { module: { exports: {} } };
        modules[index](__paeckchen_cache__[index].module, __paeckchen_cache__[index].module.exports);
    }
    return __paeckchen_cache__[index].module;
}
var modules = [
    function _0(module, exports) {
        var __import10$0 = __paeckchen_require__(1), b = __import10$0.exports['default'];
        module.exports['default'] = b;
    },
    function _1(module, exports) {
        export default '"Hello';
    }
];
__paeckchen_require__(0);

I'm not trying to be negative here, but for me a module bundler like this should output a flat bundle like e.g. Rollup does. Not like Webpack, Browserify etc where extra tons of code lines are injected (their module system).

And with the output I got with this code, I don't know what is what. I can't see my own code in it at all.

That's one of the danger with commonJS. At least when it comes with Rollup. Say you have 20 lines of code and use commonJS and have a couple of dependencies. You will end up with over 2000k lines of code.

For now I will keep an eye on this project and wait for the documentation. Maybe I did something wrong...

[ghost]

update

I found the ES6 code somewhere inside this function:

function _0(module, exports) {

I was playing around with the watch task, and noticed

• no validation
• all syntax are allowed. Even syntax that is not allowed after the spec
• no "live" update with watch if you import another module
• no errors are thrown if you try to export something that doesn't exist
• no errors thrown if you have to variabels with same name
• no injection of content from imported files

and so on...

Nice work! But I'm back to Rollup for now :)

[KnisterPeter]

Thanks for your feedback. Nice to see someone give it a try 👍
I voted against the rollup way when designing the whole architechture, because I think in the end it will be much more work to do to not have clear 'module' boundaries in the resulting bundle.
What I do with paeckchen (in case of incremental/watched build) when a file changes is just update the AST reference of one node and I am done with bundling. It couldn't get much faster in this regard.

Regarding the missing features:

• paeckchen is meant to feed with valid javascript. Its statement is doing one thing well - that means there are really good linters which will show you the errors in your code, paeckchen will never be as good and fast. And under the assumption that you fed it with only valid code every additional validation would be loss of time
• What syntax which is not in the spec do you mean? Could you give an expample please?
• What do you mean by "live" update?
• Bundling code besides JS - I've not decided if paeckchen will get this feature. Currently it is only possible to read javascript and json (and json only to be commonjs compliant - this is a widespread used requriement).

Regarding the other tasks see my first point. Doing one thing well.
But any feedback and feature request ist very much welcome.

[ghost]

Regarding the "Rollup way". That is what people most will think this days when they see a ES6 module bundler. Also the same case with me. So I was a little surprised when I saw the output :) And the fact that Facebook with React and others now are going to use Rollup in production, will not change that opinion among end-devs.

I ended up on your repo because I love TypeScript, and because I see glitches in Rollup that can't be fixed. So I was looking for an alternative. Good work there!

Regarding your TypeScript setup I'm confused :( You are using TS 2.0 now, and have a typings folder. From v. 2.0 you install what you need from NPM @types. No need for your typings folder. Then in your tsconfig.json you define it. Example:

types: ["nodes", "acorn"]

If you now open a VSCode editor you see many red lines! Meaning things aren't configured right. You will get issue with Promise. Here you can install @types/es6-promises and that issue is fixed.

You have some other types too, but here you can wrap them into a NPM package for your code and upload on NPM and install it the same way as other @types. Then your VSCode editor will be happy.

Regarding TS transpilling. Also here you do something strange. Why do you need to do so much disk write? For bundling the source itself, can't you point directly to the source folder like this:

tsc src/index.ts

I know there will be a issue with AVA. You could use ts-node, but AVA have shoot themself in the foot with the Babel integration and blocked for other type extensions such as TS, CS etc. Tape or even Tapir could solve this issues if you prefer that way to do testing.

Back to your code. I got no warnings if I did this:

import a from './a.js'
const a = 'b';
export a;

// or

export a export  export 'Hello!!' = b

// or

export b = export;

// or

export default export = 'Hello'

In Rollup there are guards against such things :)

"Live update" happen in the moment you are in watch mode and you write your code. The code changes should be visible instant in the moment you type it. It didn't happened to me.
In fact nothing happened or no changes was done when I tried to import a a second ES module. Not the module or the source code inside it.

So the "live update" was broken in my end.

How are your plugins going to work?

Great work!

[ghost]

I have to add that with TS 2.0 you have different type of type definitions build-in. E.g. you will not get access to ES6 defininations such as Map, WeakMap etc if your target isn' ES6 or ES2015. Same way you will only get type definitions for ES5 if that is your target.

[ghost]

Ich bin so weit beeindruckt! Ich mag, was ich bisher sehen. Ich war ein wenig überrascht von dem Ergebnis. Was sind Ihre Pläne als nächstes? Roadmap hat mir gesagt, nicht sehr viel. Nicht in die gleiche Falle tappen as Webpack and Browserify. Zu viel zusätzlichen Code. Wenn Sie 40 Zeilen haben, you don't want 4000 lines :)

Entschuldigen Sie die Sprache! Ich bin sehr rostig. Vor 10 Jahren arbeitete ich in Deutschland.

[KnisterPeter]

Thanks for you feedback. I'll stick with english here so others can follow. :)

Regarding your TypeScript setup I'm confused :( You are using TS 2.0 now, and have a typings folder. From v. 2.0 you install what you need from NPM @types. No need for your typings folder. Then in your tsconfig.json you define it. Example:

types: ["nodes", "acorn"]

If you now open a VSCode editor you see many red lines! Meaning things aren't configured right. You will get issue with Promise. Here you can install @types/es6-promises and that issue is fixed.

I have a mixed TS typings setup right now.

1. there are not so many typings available under the @types scope
2. I use all public available typings in @types which are possible (checked every dependency)
3. The typings I have in the typings folder are by no means complete, otherwise I would contribute them to DT, but even that does not mean that they are available under @types then
4. I'm not sure if there is something like a types key in tsconfig. At least there is no documentation for that

I'm using VSCode by myself do develop paeckchen, so I'm wondering why there are errors in your setup. Did you run npm run bootstrap in the project root and then reload VSCode?

And the Promise support should be enabled with TS 2.0 because I've set lib: ['es5', 'es2015']. The typescript compiler should therefore use the lib typings for es5 and es2015 which includes promises.

Regarding TS transpilling. Also here you do something strange. Why do you need to do so much disk write? For bundling the source itself, can't you point directly to the source folder like this:

tsc src/index.ts

I know there will be a issue with AVA. You could use ts-node, but AVA have shoot themself in the foot with the Babel integration and blocked for other type extensions such as TS, CS etc. Tape or even Tapir could solve this issues if you prefer that way to do testing.

What do you mean by 'so much disk write'? All I do in the compile script is running plain tsc without any options.
As you mentioned I need the transpiled sources for AVA to execute the tests. But that works quite well for me if you have the TSC and AVA both in watch mode next to each other.

"Live update" happen in the moment you are in watch mode and you write your code. The code changes should be visible instant in the moment you type it. It didn't happened to me.
In fact nothing happened or no changes was done when I tried to import a a second ES module. Not the module or the source code inside it.

So the "live update" was broken in my end.

Please open a separate issue for this. The watch mode should exactly do that. It would be great if you also add some details about your system (OS, node version...) so I could investigate the issue.

Back to your code. I got no warnings if I did this [...]

See above for my comments regarding code validation and error handling.
A linter should have validated your code before you give it to paeckchen.
Its all about speed and efficiency. :)

How are your plugins going to work?

The plugins are currently (and probably will stay) internal API.
Thats no final decision yet, but from my perspective a compiler/build tool/task runner (e.g. tsc, babel, gulp) could do the required transpiling/linting before bundling.
paeckchen itself should only create a single executable bundle from multiple input modules.

[KnisterPeter]

Regarding the roadmap, there are a few big things to do:

• source-maps are way too slow right now. This will be hard to fix, but I'm on this now
• caching for a blazing fast startup of paeckchen
• tree-shaking compilation like in rollup (this is probably the most difficult part)

Once this things are done we will plan the next things. :)

[ghost]

The funny thing is that I yesterday started on a similiar project like this one in TypeScript mixed with Rollup ideas. So I know how hard it is to get the TypeScript settings correct. I have been there, fixed it and happy with it :)

TS 2.0 documentaion 2.0 isn't out YET. But my tsconfig look like this

"compilerOptions": {
 "types": ["mocha", "chai", "node", "minimist", "source-map-support", "chalk", "acorn", "es6-promise"]
}

You find details here: microsoft/TypeScript#9184

and also use of dead code ellimination is a good thing in TS now. microsoft/TypeScript#6319

But once again your are blocking this when you use TS to compile to ES5. Recommended way is to use TS to ES6. Babel to ES5. That is what Microsoft suggest..

[KnisterPeter]

I'll have a look at the issues. Thanks. :)
But for one thing I'm sure: I do not want to use babel. Personally I don't like babel anymore but there are a lot of times when you need it. I think it does complicates the setup if you already have a transpiler. A second or third transpile step with watch tasks is quite complex to setup and understand.

[ghost]

I was done with Babel 5 months ago. I'm using TypeScript + ts-node + Buble and Rollup most of my time.
TS do all the magic, and Buble to transpille ES6 to ES5. It doesn't support export & import statements, but I don't care. I use TypeScript for it. But with that setup I faced issues with Rollup + TypeScript, so therefor I ended up on this repo :)

[KnisterPeter]

Buble sounds interesting. I'll need to take a look at that

[ghost]

btw. Any reason why you are not writing your tests in TS? With tests written in TS as well you will find bugs easier if you type definitions are correct.

[KnisterPeter]

The tests are written in TS ;)

[KnisterPeter]

Regarding your TypeScript setup I'm confused :( You are using TS 2.0 now, and have a typings folder. From v. 2.0 you install what you need from NPM @types. No need for your typings folder. Then in your tsconfig.json you define it. Example:

types: ["nodes", "acorn"]

If you now open a VSCode editor you see many red lines! Meaning things aren't configured right. You will get issue with Promise. Here you can install @types/es6-promises and that issue is fixed.

Did you build on the cmdline before opening VSCode?
VSCode itself does not build paeckchen and therefore the required typings may not be generated.