custom NODE_PATH and requires

[facebook]

custom NODE_PATH and requires

[Raynos]

NODE_PATH is a deprecated feature.

Making flow support all possible nodejs specific hacks based on the internal interface of module seems really complicated.

[nnarhinen]

how is NODE_PATH deprecated?

And I'm happy to change my implementation to whatever else if I still can require without having do require('../../../../../../../some/path');

[dmnd]

I think this issue can be closed after module.system.node.resolve_dirname was added in 0.18.1.

Docs are scarce but check the .flowconfig in the test in e1e301c to see how it's used.

[kunokdev]

as @dmnd mentioned; for these too lazy to search through commit changes in .flowconfig, this worked for me:

[options]
module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=src

[Raynos]

@nnarhinen

I mispoke. It was require.paths that is deprecated. NODE_PATH is a feature in node that is still supported.

However the way your using the feature is not recommended. General wisdom in the node community is that if you find yourself doing "../../../../../../../some/path" you've written a very large application and should look into breaking it out over multiple npm packages and putting more code in node_modules.

It would make sense for flow to support NODE_PATH, i.e. NODE_PATH=x flow ... if set from the cli, feature detecting for mutation of it in actual source code is a slippery slope of working on in only some cases and not all.

[Asgator]

@frontsideair look that. I finded decision problem
https://flow.org/en/docs/config/options/#toc-module-system-node-resolve-dirname-string

[MatrixFrog]

@kirushi I was doing something very similar, but I discovered that actually can hide errors from you. See #5647 (comment) -- I switched to

module.name_mapper='^\(.*\)' -> '<PROJECT_ROOT>/src/\1'

[samwgoldman]

Thanks @dmnd. I think you're right that .flowconfig option will solve the problem outlined here. We have a few features here that need to be documented, and we already have tasks to add that.

[nnarhinen]

And it's not just nodejs specific. Browserify is the most common commonjs bundler and it supports the NODE_PATH hack too.

And I just happen to use an internal interface. If I would give NODE_PATH outside of the script, then I wouldn't have to call module internal interfaces. IMO it would seem much wiser to build on top of require (or the modules browserify uses) than to use some own implementation that clearly isn't doing at its current state a very good job (#49 for instance).

[steelbrain]

+1 for NODE_PATH support

[vjpr]

+1

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[frontsideair]

I'm using nix package manager to generate the environment, which installs node packages to a folder and sets the NODE_PATH env var to that folder. We don't want to create a node_modules symlink in the working directory so we're doing all sorts of crazy hacks to make it work.

If flow can check NODE_PATH in addition to node_modules in the working directory or it could accept a command line flag for resolve_dirname, it would make our workflow much better.

[frontsideair]

I hit this problem again, and it was weird to see my comment is the last thing on the issue. I hope this can be implemented.

[Asgator]

@frontsideair me to

[kirushi]

The settings below don't return any errors on flow (albeit there being many purposely placed errors)

.env
NODE_PATH=src/

.flowconfig
[options] module.system.node.resolve_dirname=node_modules module.system.node.resolve_dirname=src

[bogdosarov]

In my case works:

module.name_mapper='^\(.*\)' -> '<PROJECT_ROOT>/src/\1'
module.file_ext=.jsx
module.file_ext=.js