-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update node deps to next breaking release #1129
Conversation
Blocked by this error:
|
I posted this comment in the upstream repo already, but just for context here: there's a PR up for optparse already, we could use the fork from there purescript-contrib/purescript-optparse#31 |
6de6e5b
to
9dbed59
Compare
CI failure when calling
|
AFAICT, there is no workaround this limitation. Either we shorten the file paths used for globs, so that each glob takes up less characters (which doesn't actually address the problem), or we update the compiler to add support for passing globs in via a file. |
I'm not sure why the current character count of 7,124 is causing problems when the limit is 8191 characters. However, without much else to go on, one of the above fixes seems to be the easiest way forward. |
On second thought, another issue here might be I think another argument for that is the fact that this test worked before this PR where we're upgrading the Node deps. |
Yup, that's the source of this issue: |
Ah, great find! 👏👏 I wonder if using I.e. do we need the new flag at all? Maybe we're just holding it wrong |
I'm not sure. What is the file content of |
Oh sorry, disregard my comment - for a moment I was convinced we were talking about the node invocation, but the Does the test you linked above pass if you set the new flag to false? |
Yeah |
But I'm wondering if that's the correct way to fix this. I was just verifying that the command parses correctly, not necessarily whether this is the right way to solve it. And I'm not entirely sure because I'm not sure what |
Some context about why the CMD wrapping is there is in the (currently active) sindresorhus/execa#578 Quoting from the thread, they say the wrapping is there to fix
So it seems to be less about what |
Rust fixed a similar issue here: https://github.com/rust-lang/rust/pull/95246/files |
So... I think there are a couple of issues being intertwined here. First, Second,
Third, installing purescript via npm on Windows makes it available via |
I think shortening to |
I'm trying to figure out when it would be safe to not do the escaping. Cross spawn's argument handling is based on Rob van der Woude's "Batch Files - Escape Characters" article, which was last updated in Nov 2019. We typically call
Of the characters in this command, we would need to escape:
Per this SO answer and the official Windows docs on path naming, special characters like We control I'm unsure of the naming convention used for dependencies (e.g.
does the directory under which Spago stores the We don't control the On another note, the original PR in Cross Spawn that refactored the argument escaping apparently did so because of a security vulnerability in NPM. Per this comment, the bug seems related to the usage of In the To conclude:
|
That ticket is a bug so we'd need to get to it anyways, and in any case without this PR we're behind upstream - so I'd merge it sooner rather than later. The root cause of the Windows misbehaviour still needs to be taken care of though |
We can't assume to be in control of any package that doesn't come from the registry. Subpackages, other local packages, and custom git repos are all possible sources of weird characters. |
I spent more time on investigating this and I have a clear path forward now. There's a few corrections from previous comments I need to make and some other updates:
I'm going to update I think Spago could be updated to the following, but let me know your thoughts:
On a different note, a given glob |
@f-f This is ready for a review. I need to document this more thoroughly, but Fabrizio and I discussed this issue and decided that the best course of action was two things:
The first fix makes it possible to merge this and move forward. The second fixes the underlying problem here. While that second fix won't help older compiler versions, we're assuming that people will upgrade over time and it'll stop being relevant. |
Thanks @JordanMartinez! I'll have a look |
src/Spago/Cmd.purs
Outdated
|
||
pure subprocess | ||
|
||
joinProcess :: forall m. MonadAff m => Execa.ExecaProcess -> m (Either ExecError ExecResult) | ||
joinProcess cp = liftAff $ cp.result | ||
joinProcess :: forall m. MonadAff m => Execa.ExecaProcess -> m ExecResult |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why remove the Either
here?
It's nice because it forces the consumer to unpack the result. Just having an ExecResult
means that one can accidentally forget to check for isSuccess
.
We could keep a Either ExecResult ExecResult
, which would be functionally equivalent, but force consumers to unpack the result of the subprocess call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are multiple times where we want to get the stdout
value regardless of whether a command failed or not. Needing to write either _.stdout _.stdout
is annoying.
Just having an ExecResult means that one can accidentally forget to check for isSuccess.
Sure, but how often is that actually going to happen? I don't think this is something that's hard to miss when reviewing, similar to how one doesn't typically forget to check for the status code of an HTTP request.
I'm not against readding the Either
, but I do think it should appear as Tuple ExecaResult (Either a b)
. I'm just not sure what a
or b
should be here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Performing an HTTP request is an operation that can succeed or fail (for a variety of reasons), and it makes sense that the result is encapsulated in an Either
.
E.g. Affjax
has request :: forall a. AffjaxDriver -> Request a -> Aff (Either Error (Response a))
We use languages like PureScript to have the typesystem - rather than human reviewers - catch things like "I forgot to unpack this result": humans get things wrong, the compiler doesn't risk forgetting.
Needing to write either _.stdout _.stdout is annoying.
I think we can have a Cmd.getStdout :: Either ExecResult ExecResult -> String
for cases like that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. I'll make the changes.
On another note, should I update |
That would be nice, but it's not a prerequisite to get this one merged 🙂 |
I'll do that in a separate PR. There might be other 'debug' hooks I should add. |
In #1129 (comment), I explained the decision Fabrizio and I reached. Below, I'd like to go into more detail, so that we can link to this post as a way to answer future questions. First, on Windows, the Second, when someone installs a JavaScript binary (e.g. However, Windows does not support symbolic links well. So, how do we get a symbolic link there? The solution is Third, when Node.js spawns a new child process, it's internally using Fourth, when Spago wants to run a
Fifth, unfortunately and as noted above, Sixth, due to Finally, as far as I could tell, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great now, thanks @JordanMartinez!
Description of the change
Next step in #1122. Currently blocked by
optparse
not being updated to latest node depsChecklist:
README
P.S.: the above checks are not compulsory to get a change merged, so you may skip them. However, taking care of them will result in less work for the maintainers and will be much appreciated 😊