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
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions dangerfile.js
Original file line number Diff line number Diff line change
Expand Up @@ -86,11 +86,15 @@ const noFlowFiles = newJsFiles

raiseIssueAboutPaths(warn, noFlowFiles, '@flow');

// 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?


// Ensure the use of 'use strict'; on all files
// Ensure the use of 'use strict' on all non-ES module files
const noStrictFiles = newJsFiles.filter(filepath => {
const content = fs.readFileSync(filepath).toString();
return !includes(content, 'use strict');
return !esModuleRegex.test(content) && !includes(content, 'use strict');
});

raiseIssueAboutPaths(fail, noStrictFiles, "'use strict'");
Expand Down