Closed davidgovea closed 4 years ago
Hi @davidgovea
I see the problem the error I am trying to fix as soon as possible but the resolving of the tailwind config file is something different.
I get the resolve problem and I was thinking to make my own command to generate a more optimised version of the config file and a specified path can be part of the command.
For the moment I see this as a different issue and a little less pressing as it still works in most of the apps were there is control over the file-structure.
If you find any solution feel free to shoot a PR for the but for now best to temporarely use v1.0.8
greetings Thomas
Hi @TVke -- I agree about the resolve issue (separate issue).
For the workaround, I've also needed to lock down the version of tailwind used:
"dependencies": {
"react-native-tailwindcss": "1.0.8",
"tailwindcss": "<1.1.0",
Looks like the error is upstream of reduce-css-calc
, in the jison
parser-generator library.
jison generates a parser.js
file, that has a "command-line-mode" fallback at the bottom of the file:
parser.js
/// ...SNIP...
exports.parser = parser; // THIS is what tailwind uses
exports.Parser = parser.Parser;
exports.parse = function () { return parser.parse.apply(parser, arguments); };
// The rest is all CLI-mode sugar. The require(fs) breaks things in RN metro bundler
exports.main = function commonjsMain(args) {
if (!args[1]) {
console.log('Usage: '+args[0]+' FILE');
process.exit(1);
}
var source = require('fs').readFileSync(require('path').normalize(args[1]), "utf8");
return exports.parser.parse(source);
};
if (typeof module !== 'undefined' && require.main === module) {
exports.main(process.argv.slice(1));
}
}
It looks like jison is pretty dead :( This PR looks like it would get us closer to a solution, but it's ..stagnant..
I'm looking into fixing it at the build-level (re-write fs.readFileSync
into a no-op? maybe rn-nodify
?), but still not a great solution
Found a maintained jison build, and made a PR here: https://github.com/MoOx/reduce-css-calc/pull/57
Will be doing more testing, but that removes the (unused) require('fs')
call from parser.js. Should fix things up once we can get tailwind to update.
@davidgovea
Thank you very much you are a hero. I didn't have time the last few weeks so thank you for being on top of it. I will tag a release to revert tailwind back to a working version and when it is fixed I will upgrade ones again.
@TVke still broken for me in v1.1.1 :cry:
error: bundling failed: Error: Unable to resolve module "fs" from
@guilherme-teodoro same here.
@TVke - can you cut another version with tailwind locked to "1.0.6"
? (or "~1.0.6"
/ "<1.1.0"
)
The current "^1.0.6"
("sem-ver compatible with 1.0.6") resolves to the latest 1.1.2 tailwind.
❯ npm ls | grep tailwindcss
└─┬ react-native-tailwindcss@1.1.1
└─┬ tailwindcss@1.1.2
verre sorry guys I just saw your messages I ment to lock it at exactly 1.0.6
and so I did in react-native-tailwindcss 1.1.2
hope it didn't cause to much troubles
reduce-css-calc is patched! 😃
Nice! And since tailwind specifies "reduce-css-calc": "^2.1.6"
, it shouldn't need to be patched.
So now a fresh install of react-native-tailwindcss@1.1.1
should work? I'll give it a try when I have a chance.
Looks like tailwind 1.1.0 started depending on reduce-css-calc, which assumes node & depends on fs
Edit: Confirmed that this happens on a freshly-generated "blank" project from expo-cli (both typescript and javascript). Let me know if there's anything else I can do to assist with reproducing.
So.. what should be done here? I've run into some unrelated problems with
require()
ing the tailwind config at build-time.. like when shipping Electrode Native "miniapps" -- the path assumption of../../../tailwind.config
doesn't work in those novel cases. I simply maintain a hardcoded patched versions for those.. not saying the library needs to adjust around these usecases.But is there value to "precompiling" the tailwind stylesheet? Could be one approach to deal with these assumptions inside the
tailwindcss
library..