@duailibe pipelines not working?

@fisker should be. Maybe it's because of merge conflicts in yarn.lock?

[...] some es6 code come up in bundle

Does not sound like an acceptable change to me unless Prettier does this in a new major release, unfortunately. (And I think there is some reluctance to make a new major release unless absolutely necessary at this point.)

I wonder if we should use some kind of tool that automatically verifies ES5 compliance, and look for some kind of simple solution for whatever cases may come up? Not needed since tests are already run on Node.js version 4, as stated below by @duailibe. My bad, apologies.

@duailibe I tried to update from master, still conflicts

@brainkim I understand we should ES5, just too much work for this update, I temp use terse to ignore some error. I will check the build and locate the problem

@fisker Did you update master?

I wonder if we should use some kind of tool that automatically verifies ES5 compliance

@brodybits we already run tests with the final bundle in Node 4

@duailibe I saw you changed the sources, so external can't work, right?

Iook like rollup-plugin-babel is not working as expected

Can you expand?

Iook like rollup-plugin-babel is not working as expected

?

As I checked, before uglify works, code should be ES5 by babel, but it's not, this is why uglify can't work

seems terser for webpack has some problem, maybe minify postcss later.

sorry, not well tested

Yeah, we can't minify postcss-parser. I'm not sure why

As I checked, before uglify works, code should be ES5 by babel, but it's not, this is why uglify can't work

I'm not sure why it didn't work, but the code is ES5 and is tested in Node 4.

Thank you @fisker! Great job!

@duailibe the third-party code looks ugly in src/, also if later we want export another separate file, we have to change source again. I think we should keep my implemention

I'm not sure why it didn't work, but the code is ES5 and is tested in Node 4.

yes, this is why I start this pr, looks code is right, so I let you decide

the third-party code looks ugly in src/

Why?

if later we want export another separate file

That's unlikely.. ideally we wouldn't even need the third-party.js.. the only reason we need it is to mock it later.

about ES5 check @brodybits mentioned before, I think there is a eslint-plugin-es may do the work

Node 4 supports a lot of ES6 stuff. See https://node.green/

@thorn0 You're right. It's not supposed to be ES5, it just needs to work in Node 4.

@duailibe Which means we can't expect uglify to parse it.

@thorn0 @duailibe is standalone.js for browsers? we don't need support old browsers?

@fisker Yes, it's for browser. We don't necessarily need to support old browsers.

We use whatever is matched by ">0.25%", "not ie 11", "not op_mini all" in browserslist.

why node 4? for node I think 8 is good enough

@thorn0 Makes sense. But it seems terser should be able to minify anything uglify also minifies, so we're safe.

The minify step is not supposed to be a check if the syntax is correct.

@duailibe problem is babel seem not working right. need more test before release

@fisker Ok, I didn't see any problem with babel. When you find out, let me know.