Parcel: Elm: typechecking newly added imported file doesn't trigger reload
π bug report
In file B, importing a new file A that doesn't initially typecheck doesn't trigger reloads on subsequent changes.
π Configuration (.babelrc, package.json, cli command)
Barebones elm project.
π€ Expected Behavior
When file A is saved, parcel reloads.
π― Current Behavior
Nothing happens when saving file A, one needs to save file B.
π Possible Solution
π Your Environment
| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.10.3
| Operating System | Linux
domenkozar
All 11 comments
cc @benthepoet
domenkozar
on 16 Oct 2018
Could be an upstream bug in https://github.com/NoRedInk/find-elm-dependencies#usage, need to test that next time it happens.
domenkozar
on 20 Oct 2018
Got this again today. findAllDependencies('./src/Main.elm').then(function(deps) { console.log(deps); }); did return the offending file. Restarting parcel fixes the issue.
@DeMoorJasper any tips how to debug how parcel picks up file changes?
domenkozar
on 30 Oct 2018
The problem might be that there is an error:
at ChildProcess.<anonymous> (/home/ielectric/dev/cachix/cachix-server/frontend/node_modules/node-elm-compiler/index.js:149:27)
at emitTwo (events.js:126:13)
at ChildProcess.emit (events.js:214:7)
at maybeClose (internal/child_process.js:925:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
I did some research on this and it seems the issue is that when the compile process throws an error, all processing of the asset halts, and any collected information such as dependencies is thrown away. At a high level, this happens in Bundler.js on line 556, and dependencies aren't watched until line 578.
There are a few ways to potentially fix this, but I think the ideal situation would be to let Asset.generate return something that indicates that the asset is in error, while still retaining other data. Maybe something as simple as {error: '...'}. One nice thing about that would be that it would make errors more of a first-class part of the pipeline and open the door for things like customizing the error display in nice ways. That could be pretty interesting with tools like Elm and Rust that produce really nice error information.
I'd be happy to try tackling this problem, but I want to make sure I'm doing work that makes sense in the context of the larger project. @DeMoorJasper or @devongovett - What's the best way to approach this? I can just start slinging code and open a PR, but if there's a particular approach you think would be best, I'm happy to go that route.
MattCheely
on 16 Nov 2018
Hi there. Sorry for commenting on this closed issue, but I'm not sure if I should raise a new issue since this feature isn't released yet.
I still experience this bug even after trying the fork mentioned in #2475 (@domenkozar: Did you do anything specific to make it work? Could you look at the example repo and see if you're able to reproduce it too?).
Steps to reproduce:
1) Edit text in Feat.elm, which is imported by Main.elm
2) Save Feat.elm
3) Expect hot reload
4) No hot reload
5) Save Main.elm
6) Hot reload happens
See this example repo and this demo video.
Any suggestions on what I can do to solve this problem?
Thanks a bunch!
sklirg
on 23 Jan 2019
How did you install the fork? To valifate you're using correct ckde, you should not see duplicate elm errors in the logs.
domenkozar
on 23 Jan 2019
I installed it by using npm install (and deleting node modules and
reinstall to make sure I didn't have conflicting versions).
The thing is that I don't have compilation errors from Elm. The code
actually compiles, but I have to trigger a save on Main.elm for the
compile+hot reload to trigger.
On Wed, Jan 23, 2019, 02:35 Domen KoΕΎar notifications@github.com wrote:
How did you install the fork? To valifate you're using correct ckde, you
should not see duplicate elm errors in the logs.β
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/parcel-bundler/parcel/issues/2147#issuecomment-456633748,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFK96zD-wUmC2gYO359ZetLKkTgGF7s6ks5vF7xXgaJpZM4Xcq0G
.
sklirg
on 23 Jan 2019
I can reproduce on your repository, but for me it works well with the same package.json pins. Not sure yet what's going on.
domenkozar
on 23 Jan 2019
Ah you're missing module Main exposing (main) on top of your Main.elm.
domenkozar
on 23 Jan 2019
This is now fixed in 1.12 (although changelog doesn't mention that).
domenkozar
on 11 Mar 2019
Related issues
dotdash
Β·
3Comments
Niggler
Β·
3Comments
urbanhop
Β·
3Comments
466023746
Β·
3Comments
will-stone
Β·
3Comments
Most helpful comment
I did some research on this and it seems the issue is that when the compile process throws an error, all processing of the asset halts, and any collected information such as dependencies is thrown away. At a high level, this happens in Bundler.js on line 556, and dependencies aren't watched until line 578.
There are a few ways to potentially fix this, but I think the ideal situation would be to let
Asset.generatereturn something that indicates that the asset is in error, while still retaining other data. Maybe something as simple as{error: '...'}. One nice thing about that would be that it would make errors more of a first-class part of the pipeline and open the door for things like customizing the error display in nice ways. That could be pretty interesting with tools like Elm and Rust that produce really nice error information.I'd be happy to try tackling this problem, but I want to make sure I'm doing work that makes sense in the context of the larger project. @DeMoorJasper or @devongovett - What's the best way to approach this? I can just start slinging code and open a PR, but if there's a particular approach you think would be best, I'm happy to go that route.