-
-
Notifications
You must be signed in to change notification settings - Fork 372
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
Automatic Babel Transformation problematic #557
Comments
Yep, a CLI flag makes sense for that 👍 |
I've run into problems related to this a few times, too. The I definitely think this is something we should be able to switch off. Perhaps it'd also be possible to change the defaults here? @DrewML Are you still going to submit a PR request for this? |
Couldn't the in-built transpiler be smarter to handle that case? I'd rather not have escape clauses if we can just cover cases right |
Yes, that might work, too. When I get back to work next week, I will try to amend the file and work out what works. :) |
I started trying to improve the built-in transpiler. However, because of the I think it should prefer Babel 7 Typescript over normal TypeScript because if you have the former you probably also have the latter for later type-checking. And additionally you are probably doing your builds with Babel 7 (does this judgement seem correct to others?). Therefore, I removed the Flow plugin from the root However, I then got an error on the I think this is because I'm now causing this to all be run with Babel TypeScript and your code wasn't written with I think it's a decent idea to prefer Babel 7 TypeScript over Native TypeScript when it is available, but do you mind if I rewrite all of your imports? 😛 |
The babel stuff is in there for testing, I think, so that could just move out of the root folder? |
Hm, I didn't know where to move it? I did what I suggested though and switched Edit: I could be completely off-base here -- do you want the behavior to be to use Babel 7 TypeScript over TypeScript or the other way around? Edit 2: I did something speculative, by trying to remove the flow plugin from the plugins array if you have the typescript plugin and vice versa. That doesn't seem to work. I think because it's not loaded the babelrc options which contains this fully yet... Fixed: but you need to be on the latest version of Babel 7. |
Cool, so: I never intended for danger-js to be transpiled with babel (I want the d.ts files to ship with the dependency) - but I did want it around specifically for writing integration tests that use babel to transpile a dangerfile (so that I was certain that it worked for people, as we always use typescript dangerfile) Having it work that was is 👍 to me, but not a goal - I just want to verify that a client can do it. Maybe babel doesn't even need to be in danger-js's |
I could do that.
Which test is this?
FYI, after I promoted Babel 7 TypeScript over plain TypeScript, it was this stuff which caused me to have to change imports (since it meant that the non-transpiled source was being used). But I guess if you want, I can remove all of the Babel packages from |
That test lives outside of jest, https://github.com/danger/danger-js/blob/master/.travis.yml#L60-L83 Yeah, I think removing it should be fine 👍 |
I can't remove Babel entirely because it causes certain unit tests to fail. |
I'm happy to have those deleted, so long as we have the async transformation validated in the fixture tests which I think is definitely happening. |
Hi, how did you resolve this issue? Was it addressed in a PR and merged or just worked around? I am trying to improve the danger-plugin-flow and using it from my repo with babel6 and flow but the plugin import fails on the
Adding EDIT: Ok, so I found EDIT2: Okay, I found a clear explanation and have a proposal for improvement. The transpilation transpiles a Dangerfile from a project that uses danger, but it follows the imports in dangerfile and tries to transpile them as well. While this is correct for local imports in Dangerfile, it should definitely not follow library imports (and especially danger plugins) and try to compile them. Would you be open for such a PR? EDIT3: Quick fix for any projects having problems with babel+flow in particular is adding a symlink from parent project to the danger plugin.
|
+9001 for allowing to disable transpilation. The Babel transpilation messes up lines & columns so when I see an error I don't know where it really comes from. With new Node.js there're not many reasons to transpile from newer JavaScript as Node.js handles these constructs just fine. JavaScript transpilation not only introduces some overhead but also causes problems while giving virtually no advantages over just using new Node.js... |
Cool, yeah sure, you're welcome to add an option, or an env var etc 👍 I use typescript for all my dangerfiles, so it's not a pain for me |
I started looking into it and I noticed there's already an env var: |
Nice, I think this is worth adding to |
Just to chime in, the default example of setting up an action with the following gets the same
|
@brandonjmckay |
got this working by adding and I'm not using the github action: - name: Danger JS
run: npx danger ci
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
Hey Orta!
Thanks for all your hard work on Danger. Fantastic tool 😃.
I'm running into an issue with the automatic Babel transformation that I wanted to discuss with you and any other collaborators before submitting a Pull Request.
My project is a pretty standard webpack/babel compiled front-end application. I'm running Danger on node 8.x, so I really do not need Babel transformation of my
dangerfile
.Right now, because of my
babel-preset-env
config for builds targeting web browsers, template literals in mydangerfile
are being compiled to ES5. This would be fine, except my.babelrc
is setup to usetransform-runtime
. This is problematic because Babel 6 has a bug wheretransform-runtime
injects import declarations rather thanrequire
calls. After this happens, Danger fails on calls to node'smodule._compile
.I can work around this issue by moving everything in my Babel config to use the
env
feature temporarily, and have no "default" babel config. However, I'm concerned that the automatic Babel transformation in Danger without an opt-out is a bit heavy-handed.Would you be willing to accept a PR that disables Babel/TypeScript transformation?
The text was updated successfully, but these errors were encountered: