Comments (20)
I use [email protected]
and [email protected]
, but it has the same errors:
node_modules/fbjs/lib/PromiseMap.js.flow:15
15: var Deferred = require('Deferred');
^^^^^^^^^^^^^^^^^^^ Deferred. Required module not found
node_modules/fbjs/lib/fetchWithRetries.js.flow:16
16: var ExecutionEnvironment = require('ExecutionEnvironment');
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ExecutionEnvironment. Required module not found
node_modules/fbjs/lib/fetchWithRetries.js.flow:19
19: var sprintf = require('sprintf');
^^^^^^^^^^^^^^^^^^ sprintf. Required module not found
node_modules/fbjs/lib/fetchWithRetries.js.flow:20
20: var fetch = require('fetch');
^^^^^^^^^^^^^^^^ fetch. Required module not found
node_modules/fbjs/lib/fetchWithRetries.js.flow:21
21: var warning = require('warning');
^^^^^^^^^^^^^^^^^^ warning. Required module not found
Found 5 errors
Ignoring works, but I have to agree with @Runn1ng that this isn't the best way...
[ignore]
.*node_modules/fbjs.*
from fbjs.
I got mine working like so, making sure to import the Promise lib first:
[libs]
./node_modules/fbjs/node_modules/promise
./node_modules/fbjs/flow/lib
from fbjs.
You probably want to exclude that with your flowconfig. For example, here's what Relay does: https://github.com/facebook/relay/blob/master/src/.flowconfig#L4
I'm going to close out since I think that's the only answer. cc @yungsters in case.
from fbjs.
I think there are some real bugs here. For example, if I track down the source of the first error:
/Path/to/my/project/node_modules/react/node_modules/fbjs/flow/include/Deferred.js:14:15,32: Promise
Required module not found
Inide flow/include/Deferred.js
we see this line: var Promise = require("Promise")
. That line comes from fbjs/lib/Deferred.js
, where it's actually var Promise = require("./Promise")
—the relative path got stripped out somehow. If the process that creates the files in flow/include
maintained the relative path, there would not be a Flow error there.
from fbjs.
The error I described above cascades and causes the second error, because Promise
is never imported, and is thus not a type:
/Path/to/my/project/node_modules/react/node_modules/fbjs/flow/include/Deferred.js:39:15,15: return
Missing annotation
(The "missing annotation" is in a return this._promise
statement, where _promise: Promise
.)
The third and forth error have the same cause as the first: relative paths become absolute.
The fifth error is weirder. flow/include/PromiseMap.js
has a line import type * as Promise from 'Promise'
but no similar line exists in fbjs/lib/PromiseMap.js
—indeed that file isn't even typechecked.
I'll have to look deeper into the workflow that generates the files in flow/include
.
from fbjs.
OK, I realize my mistake—the flow/include
files are based on the files in src
which are pre-transform and use non-relative requires. Sorry for the stream of consciousness here, but I think this is still a fbjs issue—the files in flow/include
should have relative paths like the files in lib
do.
from fbjs.
So the issue is that the gulp flow
process needs to do module mapping, similar to how gulp lib
does, using the babel plugin in scripts/babel/rewrite-modules
.
I tried changing the gulp task to the following:
gulp.task('flow', function() {
var babelOpts = assign({}, babelDefaultOptions, {
whitelist: []
});
return gulp
.src(paths.lib.src)
.pipe(gulpModuleMap(moduleMapOpts))
.pipe(babel(babelOpts))
.pipe(flatten())
.pipe(gulp.dest(paths.flowInclude));
});
Note that we don't want to actually transform any of the source code. Unfortunately, we run into errors like this:
SyntaxError: /path/to/fbjs/src/fetch/fetchWithRetries.js: Unexpected token (45:34)
43 | initWithRetries?: ?InitWithRetries
44 | ): Promise {
> 45 | var {fetchTimeout, retryDelays, ...init} = initWithRetries || {};
| ^
I confirmed over in the Babel slack channel that Babel ES7 parsing is only enabled if the accompanying transform is also enabled, but for consumption by Flow, we don't want transformations—we just want to run this plugin. @sebmck, can we work around this?
from fbjs.
Why do you want to run flow over some Babel compiled code? There's currently no way to do this.
On Tue, Aug 25, 2015 at 6:08 PM, Sam Goldman [email protected]
wrote:
So the issue is that the
gulp flow
process needs to do module mapping, similar to howgulp lib
does, using the babel plugin inscripts/babel/rewrite-modules
.
I tried changing the gulp task to the following:gulp.task('flow', function() { var babelOpts = assign({}, babelDefaultOptions, { whitelist: [] }); return gulp .src(paths.lib.src) .pipe(gulpModuleMap(moduleMapOpts)) .pipe(babel(babelOpts)) .pipe(flatten()) .pipe(gulp.dest(paths.flowInclude)); });
Note that we don't want to actually transform any of the source code. Unfortunately, we run into errors like this:
SyntaxError: /path/to/fbjs/src/fetch/fetchWithRetries.js: Unexpected token (45:34) 43 | initWithRetries?: ?InitWithRetries 44 | ): Promise { > 45 | var {fetchTimeout, retryDelays, ...init} = initWithRetries || {}; | ^
I confirmed over in the Babel slack channel that Babel ES7 parsing is only enabled if the accompanying transform is also enabled, but for consumption by Flow, we don't want transformations—we just want to run this plugin. @sebmck, can we work around this?
Reply to this email directly or view it on GitHub:
#44 (comment)
from fbjs.
@sebmck Thanks for your time. Sorry for being unclear. I'll try to be more explicit below:
There is a build process in this repo that creates files in flow/include
, the intended purpose of which is somewhat unclear to me, but it's causing Flow errors for any project that includes fbjs (including indirectly, through React 0.14 betas).
While there is a workaround (tell flow to ignore these files in every project), it's not ideal. More importantly, the errors aren't just Flow being confused about valid code. Flow is complaining about a real issue:
This code is generated using a gulp task, defined here, which flattens all the files in src
.
However, those files in src
are using some FB-defined module system that allows require "Promise"
to find the module that is annotated with @providesModule Promise
, so just flattening them isn't enough, we also need to map the modules to use relative paths, as the existing gulp lib
build command does.
This module mapping stuff is built as a babel plugin. So, in order to create files which can be analyzed by Flow, we need to module map, and thus go through Babel—but just for the plugin, not for any transforms.
So, I tried to modify the gulp flow
build step to use the same module mapper plugin, but not any transforms (whitelist: []). Since the code in src
uses ES7 features, this fails at the babel parser step, which disables parsing for ES7 syntax unless the relevant transforms are enabled.
Now, maybe this is all moot, because the code in flow/include
is kind of mysterious to me. Maybe the better solution is to omit these files from the npm package, since I don't think they are useful to anyone, except maybe FB?
from fbjs.
The flow config in you need in your destination project is a bit unruly at the moment.
You need both of these, otherwise you get issues with Deferred.
[lib]
../node_modules/fbjs/flow/include
../node_modules/fbjs/node_modules/promise
If you're using React you'll also need to ignore react node_modules
[ignore]
.*/react/node_modules/.*
You might also need to tell flow to use the Haste module system so that it resolves the modules right.
[options]
module.system=haste
This is probably the main problem that you're having BUT it might also not be right for you. This would be the main problem but it's also tricky because we do use Haste and you probably don't. It might still work though since I would hope Flow does a good job of actually resolving when it needs to.
All of the above code bits came from the Relay flowconfig where this is working which is why I linked to it above. So it is possible but there are probably some issues when fbjs is a nested dependency.
If you are consuming the code here and you are not also a Facebook project, be prepared for a bad time.
I put that in the readme for a reason :) We're still figuring out how to make this work in a general way but we are optimizing for ourselves so that we can ship things like Relay faster.
Maybe the better solution is to omit these files from the npm package, since I don't think they are useful to anyone, except maybe FB?
The original goal was to embed the type annotations in the files themselves via the comment syntax, and we did that initially. But the comment syntax doesn't support the full range of Flow capabilities (namely polymorphic classes, see #23) so we decided to ship the original source which we know Flow does understand.
Perhaps another way around this until inline comments is viable is to instead ship fbjs-flow as a standalone package, only used as a devDep. I'm not sure how that will work when fbjs is a nested dependency and you want to typecheck.
from fbjs.
@samwgoldman what would be really helpful is if you could create a sample project showing what you're doing and the use case you'd like us to support. Otherwise we're working a bit of a black box and dealing in hypotheticals and assumptions.
from fbjs.
@zpao Sure. And, for what it's worth, I'm pulling this thread from the perspective of a frequent Flow contributor who wants to make it easier for people to get started using Flow. Right now it's not a great experience, and I want to improve it to improve adoption of Flow. I'll follow up with a repo.
from fbjs.
Perfect, thanks! (and thanks for the work on Flow, I know the team appreciates all the help and it's great to have somebody coming at this problem from that side)
from fbjs.
@zpao https://github.com/samwgoldman/issue-react-flow-setup
from fbjs.
For anyone else trying to use flow and completely lost like I just was, if you are using node 5 you need to add these lines to your .flowconfig
instead (due to how npm 3 flattens the dependency tree):
[ignore]
.*node_modules/fbjs.*
.*node_modules/webpack.*
from fbjs.
Hm. I don't like that. I don't want to ignore modules that are using Flow.... intuitively speaking, isn't it the opposite of what I would want?
When a module is using flow, I want to use its declarations and so on, instead of ignoring it.
But maybe I am just lost in this include/ignore/module thing
from fbjs.
In fbjs 0.6, the definitions are included in a way that should work better with Flow. I can't promise how well it works but it may work better than it did previously.
from fbjs.
Oh. The flux example is using old react, it seems! Which, then, uses old fbjs, which causes the errors! That might be the reason. I will try to update the flux example with new react, that might fix it
from fbjs.
Oh. No. It's because flux explicitly has a dependency on 0.4.0 version of fbjs. Well, let's try to update that...
from fbjs.
No. When I explicitly update fbjs to 0.6.0 in the flux example (via changing it in the flux node dependency), it still does the same error, with failing to include Promise :-(
(sorry for so many messages!)
from fbjs.
Related Issues (20)
- CVE-2017-16086 found in ua-parser.js HOT 2
- ua-parser-js to fix Regular Expression Denial Of Service (ReDoS) HOT 1
- areEqual doesn't support objects with null prototypes
- Got error "Cannot destructure property 'instrument' of 'options' as it is undefined" when using with jest:27.0.4 HOT 2
- missing v3.0.0 relase and tag HOT 1
- ua-parser-js Dependency Security vulnerability HOT 1
- 'instrument' required, then optional? Resulting in `TypeError: Cannot destructure property 'instrument' of 'options' as it is undefined.`
- fbjs > [email protected]: this package has been hijacked HOT 1
- [security-update] Update ua-parser-js dependency in fbjs HOT 1
- "ua-parser-js": "0.7.30" have a wrong HOT 3
- Security vulnerability with cross-fetch in fbjs HOT 3
- ChainAlert: new npm maintainer has published version 3.0.3 of package fbjs HOT 3
- Git.io deprecation notice
- upgrade core-js version HOT 1
- ua-parser-js ReDoS Vulnerability HOT 1
- nullthrows has either bad condition or bad error message HOT 1
- Analysis: 100% of dependency updates in this repository can be merged.
- Deprecated babel plugins HOT 3
- ua-parser-js changing to AGPL license in v2.x
- Consider removing `cross-fetch` dependency
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fbjs.