New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WTF with 6to5-runtime? #369

Closed
valeriangalliat opened this Issue Feb 14, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@valeriangalliat
Member

valeriangalliat commented Feb 14, 2015

We need to find a decent way to depend on 6to5-runtime without it breaking SassDoc when newer 6to5-runtime versions are published… not sure a hardcoded strict version like done in 8bab189 is the right solution.

@valeriangalliat valeriangalliat added the Bug label Feb 14, 2015

@pascalduez

This comment has been minimized.

Show comment
Hide comment
@pascalduez

pascalduez Feb 14, 2015

Member

I'm starting more and more to limit my usage of ES6 features to a restricted set, so I can ship code not runtime dependent or exposed to versions break, global scope or native hijacking, and all that jazz.
See 3bbea0c
In sassdoc' case that would mean renouncing to async functions I guess, which sucks. So I don't know.
A fixed dependency is not that bad.

Member

pascalduez commented Feb 14, 2015

I'm starting more and more to limit my usage of ES6 features to a restricted set, so I can ship code not runtime dependent or exposed to versions break, global scope or native hijacking, and all that jazz.
See 3bbea0c
In sassdoc' case that would mean renouncing to async functions I guess, which sucks. So I don't know.
A fixed dependency is not that bad.

@valeriangalliat

This comment has been minimized.

Show comment
Hide comment
@valeriangalliat

valeriangalliat Feb 15, 2015

Member

I'm starting more and more to limit my usage of ES6 features to a restricted set, so I can ship code not runtime dependent or exposed to versions break, global scope or native hijacking, and all that jazz.

I agree with this philosophy.

Not sure we have to renounce to async functions, we can, well, still use regenerator, and some library providing Promise.do or equivalent. But using a raw promise flow instead of async functions is acceptable to me.

About this very issue, I think there's probably a bug with 6to5, or a non-BC change, or we're not using 6to5 properly? I'm still not sure how we should use 6to5 as a library developers, I can't find documentation extensive about this. Looks like selfContained with runtime is nice, but now, what about version requirements, compatibility with 6to5 and 6to5-runtime dependency? They just say npm install --save 6to5-runtime as we did.

BTW @pascalduez if we start using Bluebird, we can tell 6to5 to compile async functions as coroutines!

Member

valeriangalliat commented Feb 15, 2015

I'm starting more and more to limit my usage of ES6 features to a restricted set, so I can ship code not runtime dependent or exposed to versions break, global scope or native hijacking, and all that jazz.

I agree with this philosophy.

Not sure we have to renounce to async functions, we can, well, still use regenerator, and some library providing Promise.do or equivalent. But using a raw promise flow instead of async functions is acceptable to me.

About this very issue, I think there's probably a bug with 6to5, or a non-BC change, or we're not using 6to5 properly? I'm still not sure how we should use 6to5 as a library developers, I can't find documentation extensive about this. Looks like selfContained with runtime is nice, but now, what about version requirements, compatibility with 6to5 and 6to5-runtime dependency? They just say npm install --save 6to5-runtime as we did.

BTW @pascalduez if we start using Bluebird, we can tell 6to5 to compile async functions as coroutines!

@pascalduez

This comment has been minimized.

Show comment
Hide comment
@pascalduez

pascalduez Feb 15, 2015

Member

I don't feel we are doing something wrong, It looks like they are intensely active to patch and release, breaking things along the road... But fixing them as quick though.
We could either fix the dependency, or allow only patches.

Last time I checked Bluebird coroutines required the --harmony flag. And apparently even Node 0.12 doesn't support generators. Seducing idea though.

Member

pascalduez commented Feb 15, 2015

I don't feel we are doing something wrong, It looks like they are intensely active to patch and release, breaking things along the road... But fixing them as quick though.
We could either fix the dependency, or allow only patches.

Last time I checked Bluebird coroutines required the --harmony flag. And apparently even Node 0.12 doesn't support generators. Seducing idea though.

@HugoGiraudel

This comment has been minimized.

Show comment
Hide comment
@HugoGiraudel

HugoGiraudel Feb 16, 2015

Member

So what is the idea here? :x

Member

HugoGiraudel commented Feb 16, 2015

So what is the idea here? :x

@valeriangalliat

This comment has been minimized.

Show comment
Hide comment
@valeriangalliat

valeriangalliat Feb 16, 2015

Member

Currently, we stick with hardcoded 6to5 version. We may allow patch…

Bumping minor should require manual check, according to previous experiences.

Member

valeriangalliat commented Feb 16, 2015

Currently, we stick with hardcoded 6to5 version. We may allow patch…

Bumping minor should require manual check, according to previous experiences.

pascalduez added a commit that referenced this issue Feb 16, 2015

Update `sass-convert` dependency
Prevent the 6to5 runtime issue specified in #369
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment