search

jscheid / prettier.el

Prettier code formatting for Emacs.
GNU General Public License v3.0
167 stars 12 forks source link

Prepare for MELPA PR (work in progress) #13

Closed jscheid closed 4 years ago

aspiers commented 4 years ago

Ah, I just found this - looks great! What is left to be done?

jscheid commented 4 years ago

@aspiers mainly deciding if this is really the way to go, and then some testing and updating the docs.

I despise the idea of checking binaries into VC, here I'm exploring it as the potentially least bad option, relative to the amount of work that would need to be done for other solutions such as switching to using diff(1).

I'd be keen to hear your thoughts, you appear to be in favor?

aspiers commented 4 years ago

I also generally despise checking binaries into VC ;-) But maybe it's not a terrible compromise in this case - I'm not sure, because I don't entirely understand yet how the blob is used. How about wrapping make prettier-el.js.gz.base64 into an elisp defun which is called just-in-time before it is needed?

jscheid commented 4 years ago

What exactly are you suggesting, to check in the "linked" prettier-el.js, but uncompressed so that it's less of a blob? Or to link it on demand?

In the former case, I don't know if it would be an improvement; with optimizations enabled it's still mostly inscrutable, and disabling optimizations just for the sake of making it less opaque would be somewhat sad. Ultimately, we'd still be checking in build output.

In the latter, it currently needs a fairly specific build environment, and Emacs packages don't usually need to run a build step after installation. I'd foresee much frustration and need for hand-holding here on Github issues.

aspiers commented 4 years ago

@jscheid commented on June 10, 2020 12:49 PM:

What exactly are you suggesting, to check in the "linked" prettier-el.js,

I'm not sure what you mean by "linked"? And this file is already in git, so maybe I'm misunderstanding something.

but uncompressed so that it's less of a blob? Or to link it on demand?

No, I'm suggesting writing some elisp which generates the base64 file from the source just-in-time, and that it could reuse the existing Makefile rule.

In the former case, I don't know if it would be an improvement; with optimizations enabled it's still mostly inscrutable, and disabling optimizations just for the sake of making it less opaque would be somewhat sad. Ultimately, we'd still be checking in build output.

Right. I'm not proposing that.

In the latter, it currently needs a fairly specific build environment, and Emacs packages don't usually need to run a build step after installation. I'd foresee much frustration and need for hand-holding here on Github issues.

Right, that's why I've been inclined to propose dealing with this in a CI pipeline. Can GitHub publish build artefacts from non-release builds?

jscheid commented 4 years ago

I'm not sure what you mean by "linked"? And this file is already in git, so maybe I'm misunderstanding something.

By "linked" I mean the step that bundles prettier-el.js with diff-match-patch, which isn't really linking, hence the quotes. And yes, sorry, I meant prettier-min.el.js.

Right, that's why I've been inclined to propose dealing with this in a CI pipeline. Can GitHub publish build artefacts from non-release builds?

Good question, I guess it depends on what you mean by publish. For Melpa to pick things up, the artifacts would have to be pushed into VC again, right? That should be possible but we'd be getting into Rube Goldberg territory :-)

aspiers commented 4 years ago

For Melpa to pick things up, the artifacts would have to be pushed into VC again, right?

Ahhh, I thought there was a vanilla http :fetcher which could have been used to download artifacts from anywhere, but apparently not :-( I guess that changes things.

jscheid commented 4 years ago

Superseded by #25