Skip to content
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

Patch dangerfile to only do "use strict" checks on non-es modules #2709

Merged
merged 1 commit into from
Jan 26, 2017

Conversation

quantizor
Copy link
Contributor

ES modules are strict mode by default, so the check should look for use of "import"/"export" to determine if flagging is required.

Closes #2708

ES modules are strict mode by default, so the check should look
for use of "import"/"export" to determine if flagging is required.
@quantizor quantizor changed the title Patch dangerfile to only do use strict checks on non-es modules Patch dangerfile to only do "use strict" checks on non-es modules Jan 26, 2017
@codecov-io
Copy link

codecov-io commented Jan 26, 2017

Current coverage is 68.35% (diff: 100%)

Merging #2709 into master will not change coverage

@@             master      #2709   diff @@
==========================================
  Files           140        140          
  Lines          5060       5060          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits           3459       3459          
  Misses         1601       1601          
  Partials          0          0          

Powered by Codecov. Last update a8514b2...2357030

@cpojer cpojer merged commit ce8d31c into jestjs:master Jan 26, 2017
// based on assumptions from https://github.com/nodejs/node/wiki/ES6-Module-Detection-in-Node
// basically it needs to contain at least one line with import or export at the
// beginning of it, followed by a space; any content thereafter doesn't matter
const esModuleRegex = /^(import|export)\s/g;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will actually also include Flow types imports/exports

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh no. We need to fix this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK is there any indicator that a Flow file is a Flow file?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has a @flow inside.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah OK, I'll send a follow-up PR later today

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thymikee Hmm so this is somewhat complicated... since files that are typed by Flow also have the @flow comment, it's nearly impossible to differentiate the flow type files from normal ES modules. What do you recommend here, should I just roll back this change?

In general I'm a little confused by the fact that flow uses ES module-like import syntax. Does that mean those files need transpilation via Babel?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flow uses import type/export type syntax, so I think you can safely match it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, but it seems like it's using ES module-like syntax in a commonjs file? Does using flow automatically make a file an es module? If so, that's fine and we don't actually have to change anything.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it doesn't, it's a Flow convenience syntax that is being stripped by babel transform so node module resolver shouldn't be aware of it anyway, but I'm not 100% sure. @cpojer?

skovhus pushed a commit to skovhus/jest that referenced this pull request Apr 29, 2017
…js#2709)

ES modules are strict mode by default, so the check should look
for use of "import"/"export" to determine if flagging is required.
tushardhole pushed a commit to tushardhole/jest that referenced this pull request Aug 21, 2017
…js#2709)

ES modules are strict mode by default, so the check should look
for use of "import"/"export" to determine if flagging is required.
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"Danger" bot doesn't need to ask for strict mode for ES Modules
5 participants