rrdelaney / bs-loader Goto Github PK

mll/mly generate ml/mli in build dir and output to dist dir

super-errors provide really nice error messages, but aren't parsed correctly by bs-loader. We should add the case in out error handling regex: https://github.com/reasonml-community/bs-loader/blob/29c72844eba4f4972e032630e592454ce57cdd04/index.js#L19

https://github.com/garkin/bs_loader_webpack_watch_bug

Steps to reproduce

1. git clone https://github.com/garkin/bs_loader_webpack_watch_bug
2. npm install
3. npm start to start watching using webpack
4. Uncomment some syntax error line in the src/fib.re to break program and get an error
5. Comment back some syntax error line in the src/fib.re to restore program correctness

Expected behavior:

After removing error in src/fib.re - changes are recompiled and we get console output about succesfull recompilation.

Actual behavior:

(5.) and further src/fib.re changes are not recompiled and we do not get updates in the console.
But changes in the entry src/index.re do trigger correct recompilation.

Environment:

Windows 10 
NodeJS v6.9.1

Centos 7
Linux 3.18.17-13.el7.x86_64
NodeJS v6.10.3

"bs-loader": "1.2.5"
"bs-platform": "1.7.4"
"reason-js": "0.3.0"
"webpack": "2.6.1"

I.e. .rei/.mli files. Is this just a configuration issue?

I tried cloning down the repo and running yarn build in examples/es6. It fails with:

ERROR in ./src/print.re
Module not found: Error: Can't resolve './add.js' in '/Users/dan/projects/sandbox/bs-loader/examples/es6/src'
 @ ./src/print.re 4:0-34

ERROR in ./src/print.re
Module not found: Error: Can't resolve './fib.js' in '/Users/dan/projects/sandbox/bs-loader/examples/es6/src'
 @ ./src/print.re 5:0-34```

I just tried this loader and it doesn't work. When the loader internally triggers bsb and it compiles re module, which contains dependency, loader returns string with required js dependency, but webpack can't resolve it as its context is in src folder (where re module resides), but not in output lib/js folder.

I see that in your implementation you hard coded the loader to look for lib js however in order to take advantage of tree shaking we must tell bs to not use commonjs and instead use es6. Would it be possible for you to check the bsconfig field package-specs for es6? There are several other module formats and bs makes separate folders for these.

I am just starting with reason and I am configuring webpack-dev-server to work with it.
Seems that the loader is working fine, and it is transpiling the files, but when I change one of the .re files, webpack won't see the changes. I need to restart it in full to get an update.

Have you had this issue before please?

For reference here is my config:
https://github.com/adamgajzlerowicz/skeletoon/tree/reason/frontend

'script' unix command is broken on WSL. And bs-loader uses it. This is what is breaking bs-loader on WSL. And all projects that uses bs-loader, including reason-scripts.

Issue on BashOnWindows: script command fails, Function not implemented

I wish there was an option to hide warnings only for dependencies, I think it's possible to match a filePath to understand whether an error is from ./node_modules/.

Does it make any sense to do so? Would you accept such PR?

The react template that comes with bsb (bsb -init <...> -theme react) uses webpack1, which apparently isn't quite compatible with the recommended configuration for bs-loader. More specifically, the resolution algorithm seems to be different (it tries to resolve foo.re.re for some silly reason), and the loader might need to be configured differently as well. I didn't fool around with this too much before figuring I'd better look at what the example projects here are using (which is webpack3).

I think it might be a good idea to warn about webpack1 incompatibility, add a requirements section or some such thing, and perhaps we should also change the react template to avoid this confusion.

cc @chenglou

By reading the bsconfig we could skip the options part of webpack.

The downside would be that bsconfig supports trailing commas and comments in JSON which we don't have access to AFAIK.

I would really love this, since it could allow users to pick their style when using reason-scripts witouth ejecting it also prevents non reason-scripts users from making simple mistakes like, updating the options in webpack but not their bsconfig.

Do you have any thoughts on this @rrdelaney

Without a testMatch config in package.json bs-loader will pass along paths like my-project/lib/js/lib/js/__tests__/foo_test.js (note the duplicate lib/js), which obviously isn't going to be there. The correct path in this case should be my-project/lib/js/__tests__/foo_test.js

Hi, any news on shipping that feature?

https://github.com/reasonml-community/bs-loader/blob/9a946ab477e16e627b21a7c4fed2cead6e791bc7/packages/bs-loader/index.js#L32-L33

bsb will compile upper-cased file to lower case e.g. TodoApp.re => todoApp.js in linux, see: rescript-lang/rescript-compiler#913

then webpack throw an error: cannot find src/todoApp in ....

Is there a way to work around this?

Error is:

Cannot find module '../src/jest.js' from 'expect_test.js'

and so on for each test file.

repro script:

git clone https://github.com/buckletypes/bs-jest
cd bs-jest
git checkout bs-loader
npm link bs-platform
npm i
node_modules/jest/bin/jest.js

Workaround is to just add bsb -make-world && before jest in the appropriate npm scripts

Alpine linux for example doesn't seem to come with the script command, nor is any kind of bsdutils package available. I use alpine in my build environment, I had the hardest time tracking down what

./src/index.re
/bin/sh: script: not found

meant. Anyhow, what benefit does that actually provide here? Would it be reasonable to disable it via ENV variable, or check if it is available in the PATH before trying to use it?

Hey so I'm using bs-loader within a project called qnd. I'm stress testing qnd right now on the kanban project found in the examples of the repo. If I feed qnd reason files for the entry file they are passed through bs-loader and then bucklescript will throw END OF FILE errors. If I instead feed qnd the bs output there are no errors. Any clue why this may be going on?

We have a bs-config with "sources": [../src] and bs-loader thinks that the path to that source is:

/Users/x/path/to/bsconfig/dir/Users/x/path/to/bsconfig/dir/../src