Closed hdgarrood closed 5 years ago
@nwolverson do you think you might be able to take a look at this? there are just two tests which are failing, which are related to browserifying with source maps. I first suspected that the change to Node.Path.resolve
(which previously returned a String
, now returns an Effect String
) was the culprit, but I tried replacing it with a version which just returned a String
, and no dice. Now I have no clue what could have caused this to stop working.
Has the browserify version changed at all? I remember the path resolution stuff being a nightmare to get right in all scenarios. I'll take a look when I can but honestly if it's not a trivial change I'd be minded to delete the source-maps for browserify support.
Fair enough. I did recently update the versions of both browserify and sorcery, but the CI is passing in master
(which are using those same updated versions).
I've had a new thought though: perhaps this is related to https://github.com/purescript/purescript/pull/3314?
I've actually been thinking more recently that I'm not sure it makes sense to have a dedicated browserify
command. The important difference between browserify
and build
is that the former pulls in npm dependencies, right? If that's all there is to it, I'd be tempted to do the following:
build
which specifies whether or not to include npm dependencies in the bundle,browserify
in favour of this new option,If someone knows they want browserify
specifically, I think it's safe to assume that they're capable enough to set it up themselves, separately from Pulp.
Ok, the same problem does exist in pulp 12.3.1, it isn't a result of this PR. It must be to do with something that changed in the compiler in the 0.12.0 release; I'm betting it is indeed https://github.com/purescript/purescript/pull/3314. The reason we're only just seeing this in CI is that we were previously only testing against purs 0.11.x, and now we're testing against purs 0.12.x instead. I'm going to just mark the failing tests as pending for now so I can get this merged.
Eventually we should provide a mechanism for running tests against more than one compiler version (although the test suite is so slow as it is, I am slightly nervous about how long it would take to run the whole test suite twice...)
I'll try and take a look sometime, good to have the cause narrowed down.
Following on from #360