-
-
Notifications
You must be signed in to change notification settings - Fork 450
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
hash current Babel options state to cache path #62
Comments
There's a slightly different version on the develop branch. Do you want to give it a go and tell me if it still happens? (I mean using the cacheIdentifier) |
I'm closing this due inactivity. Anything else just give it a shout and I'll re-open the issue. |
This came up for us on react-bootstrap/react-bootstrap#840 - it'd be great if |
If you want to change the Either that or I might not be understanding the problem correctly. |
I could certainly do that, but I think it would be nice if The reason I think that's the case is because we saw an issue where we added I believe this kind of condition where a user changes |
I can easily agree that the user would expect the cache to be invalidated, however I'm not sure if it's the loader's responsibility to actually gather info from Anyway, I'll try to work on this tomorrow morning, since it's quite late in here. |
Sadly it's going to be a bit messy, because I think you'd have to use https://github.com/babel/babel/blob/master/src/babel/transformation/file/options/resolve-rc.js , which is likely to make @sebmck unhappy. But I don't know if there's a better option. |
If you hotlink to my internal APIs then I will cry |
@sebmck you and me... specially because babel moves really fast which would mean constant updates on my part. Might try to duplicate the resolve rc functionality into the loader. but anyway... so far it's just me talking, I will try to mess around to see what I can do. |
Ok... sorry for taking so long, I'm having a hard time to find some free time. A proof of concept can be found on the feature/resolve-rc... it's hardly tested, but it seems to work on my examples. I was wondering if you're up to test it on your project, and I'm open for opinions. The option to use
|
This is really cool, thanks. What's the benefit of making this opt-in rather than opt-out? It seems like one would usually strongly prefer to have this feature, no? BTW, might make sense to use https://www.npmjs.com/package/json-stable-stringify instead of the standard |
The reason why it's opt-in is mostly to avoid a new unexpected behaviour for the ones already using the cache feature. Still... this is a work in progress. I'm happy for any input :) On June 18, 2015 5:45:34 PM GMT+01:00, Jimmy Jia notifications@github.com wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
I really like this, BTW. I think I'd pretty much use it everywhere. |
I like this feature a lot and would switch to using it in all cases where I'm currently using cache directory, as it will allow me to get rid of fragile logic for bypassing the cache only for particular builds. Are there any concerns preventing it from being merged? |
I've just merged this feature. |
Awesome. Thanks! |
I'm closing this, since it has been merged. |
I haven't tested it, but does this work if the |
At the moment it doesn't, however a PR should not be too hard :) |
hi.
for example, I have
.babelrc
:and I keep getting the same cached version if I just want to rebuild my bundle from
development
env toproduction
w/o any files changes.rm babel-loader-*
fromrequire('os').tmpdir()
helps once :)so imo current options state needs to be stored somewhere here, but I can't figure out how to get it from
babel
to make a PR.The text was updated successfully, but these errors were encountered: