You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, most imports in 🍉 are absolute (i.e. import from 'Query'). This is mostly an artifact of the fact that it was extracted from a codebase of an app. But it's also very convenient when working on Watermelon.
But it adds A LOT of complexity, because every tool that has to understand the codebase has to be (often separately) configured:
the app and Jest in an app importing Watermelon (we use Babel to rewrite for dist)
Flow in the app importing Watermelon (also using Babel but have to write a separate copy with Flow annotations — which has its own problems… - see [Discussion] Better Flow setup #21 )
I see 3 options:
We keep the current setup (This is a big PITA)
We give up and just change the absolute paths to relative paths.
We meet halfway and change all paths to something like ~/blah or src/blah. I think it's not much better than 1. We still have to configure the same number of tools, it's just that there's one item in the config.
Personally I think it's easiest to go with (2). It's a little less convenient when refactoring, but I think overall a smaller maintenance burden. But I don't have experience with shipping NPM packages, and I don't know what other larger JS libraries do.
The text was updated successfully, but these errors were encountered:
Facebook uses this kind of module system, haste? IMO relative paths are better, no confusion about where the module is, no configuration needed for tools etc.
Yeah, but haste is not exactly absolute paths, I think it searches the whole tree to find the right package. And haste is specific to Facebook tools, isn't universal
Currently, most imports in 🍉 are absolute (i.e.
import from 'Query'
). This is mostly an artifact of the fact that it was extracted from a codebase of an app. But it's also very convenient when working on Watermelon.But it adds A LOT of complexity, because every tool that has to understand the codebase has to be (often separately) configured:
I see 3 options:
~/blah
orsrc/blah
. I think it's not much better than 1. We still have to configure the same number of tools, it's just that there's one item in the config.Personally I think it's easiest to go with (2). It's a little less convenient when refactoring, but I think overall a smaller maintenance burden. But I don't have experience with shipping NPM packages, and I don't know what other larger JS libraries do.
The text was updated successfully, but these errors were encountered: