Update Rollup

[simonhaenisch]

This updates Rollup to the latest version (1.1.0) which introduced breaking changes (see this PR: rollup/rollup#2293).

The main difference is that Rollup's bundle.generate now returns a different format.

experimentalCodeSplitting is on by default now and has been removed, so I removed it from the Rollup config.

For src/compiler/bundle/write-bundles.ts, I had to map the array into a different format: previously the chunks were returned as an object

{ filename1: 'code', filename2: 'code' }

, but now it is an array of objects:

[ { fileName: 'filename1', code: 'code' }, { fileName: 'filename2', code: 'code' } ]

Not sure whether my .map and .reduce approach is bad performance-wise (I didn't notice a difference for my project)... it might be better to change the signature of the receiving function in order to avoid this transformation?

Closes #1306.

[simonhaenisch]

@adamdbradley I looked into fixing the tests and they all fail with the same error because of an upstream issue of rollup-plugin-node-resolve in browserify/resolve.

E. g. for service-worker.spec.ts, somewhere it tries to resolve ./components/cmp-a/cmp-a.js with /src as the basedir (which might be an error on our part because it's supposed to be a relative ./src? or shouldn't matter because of the in-memory fs?). There is now a fs.realpath check in path.resolve, which assumes that /src/components/cmp-a/cmp-a.js is an absolute path because it starts with a / and thus fails, and then there is some faulty code that passes on undefined as the basedir.

Here is the related code: https://github.com/browserify/resolve/blob/v1.9.0/lib/async.js#L47-L50. It breaks the init(realStart) because realStart is undefined in this case.

I switched out init(realStart) with init(realStart || absoluteStart) and then all the tests pass again.

I now found out that there is already a fix for this in master, but the latest resolve version (1.9.0) was released without it (see browserify/resolve#177 (comment)) because apparently it's a breaking change. I'll try find out there when that fix will be released. I suggested a patch for this upstream issue (browserify/resolve#181), and waiting for it to get released.

[simonhaenisch]

The AppVeyor build fail seems to be unrelated as the same thing fails in other PRs as well (I'm pretty sure it's because of how normalizePath from compiler/util.ts is used).

The karma test fails because it tries to generate a bundle with entry test-app/global.ts which somehow doesn't get transpiled?

Rollup: Parse Error: test-app/global.ts:3:8
Unexpected token (Note that you need plugins to import files that are not JavaScript)

Would be nice if someone could point me in the right direction as to why this happens, as I use a globalScript in my own project as well which compiles successfully. First I thought the issue is that it's not part of the includes in the tsconfig, but that didn't fix it.

[manucorporat]

Does rollup uses browserify/resolve? yep i noticed the same problem with undefined, I would be super happy to merge this PR once this issue with undefined is resolved.

Btw, thanks a lot for the PR!

[simonhaenisch]

Does rollup uses browserify/resolve?

Not Rollup itself, but rollup-plugin-node-resolve. I already fixed the upstream issue but waiting for the patch to be accepted and released.

A workaround I found is to pass preserveSymlinks: true to the node-resolve plugin config, which I did in this PR, but I actually want to undo it again because I don't think it should be set(?).

@manucorporat any idea about why Rollup would fail with the globalScript in the karma test? It's like it doesn't accept the .ts extension or something, but I don't understand why because it works with my globalScript in my project.

[adamdbradley]

Ok, I'll dig into this more, thanks

[adamdbradley]

thanks!!! I've got some fixes after this merge too that should get everything up to speed.

[bitflower]

Nice, just got it in Stencil 0.16.4