works fine when manually triggering it.
Installing “atom-beautify@0.28.7” failed.Hide output…
spawn-sync@1.0.11 postinstall C:\Users\ADMINI~1\AppData\Local\Temp\apm-install-dir-11567-12976-7d72bu\node_modules\atom-beautify\node_modules\cross-spawn\node_modules\spawn-sync
node postinstall
npm
don't understand why
@Glavin001 I have started off a wiki on Github. I have seen some really good info recently that can be applied to multiple users.
Hey @Glavin001, I love this plugin and use it all the time. However, the update time takes forever for some reason. Is this normal? Also, this made me start thinking about the codebase, it is one single plugin for all these different language beautifiers. Would it make sense to structure it more like linter, where you have a main beautifier plugin that defines the API for each language beautifier to interface with and allows developers to install only beautifiers that they will use?
@stramel I'd recommend that issue, #320
I would really appreciate feedback and any new ideas on this matter
The disadvantage with lazy loading the beautified dependencies being that it would need to be loaded when the beautified is used, so the first time the user uses the beautified after an update it will not immediately work.
So you must install linter, and linter-language etc
nevermind
I think I like the approach linter took with separate packages
For instance, I never really use any beautifier other than a handful. So for me it is definitely beneficial to only load those handfuls. It would also make updates shorter since each package is small and managed separately
I want Atom Beautify to be the one-stop place for all code beautification in Atom. As of #282, each beautifier is very light-weight itself (e.g. https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/autopep8.coffee ) and it'd be annoying for me to maintain at least (currently) 15 small repos for each beautifier, when right now they are simply files. So I am not supportive of splitting into separate modules, as the linter package does.
Essentially, I picture it as Atom Beautify being able to recognize each language it supports and then effectively install each module upon usage. Like linter package, except auto-installing: you do not need to install linter and then linter-coffeescript, you simply install linter and try to lint CoffeeScript and it will detect that it is supported and install it for you.
Please leave your feedback on the Issue #320 :).
I have been looking at this over the last two weeks. I am going to publish an update today that radically changes the architecture of Pretty Diff, and so I also plan to reduce the size of the npm package. The current package as of v1.13.8 is 8480kb. With my code changes that I am about to launch I anticipate the package will become about 2mb.
I think typescript formatter was much bigger than that lol
@yardimli would you mind creating a github issue and pasting your code sample to a gist? github issue - https://github.com/Glavin001/atom-beautify/issues gist - http://gist.github.com/
See Glavin001/atom-beautify#453
clemf could you open an issue on Github and provide a code sample so that I can reproduce the problem? https://github.com/Glavin001/atom-beautify/issues
@clemf
I assume I'm just missing a setting, but when I format jsx code, beautify is adding a newlines where I don't want it to - Is there a way to stop this? I don't see jsx in the settings and assume it's handled as part of javascript? I think it might be a line length issue? but it splits things on dots, and it is splitting properties like {{myvar}}, etc. I'd rather have long lines than super expanded code blocks on 10 lines...
oh i just found the jsx @prettydiff config section, but there seems to be no settings? is there some where else I need to look?
@prettydiff Here you go: https://gist.github.com/andrewserff/e53d0547533c38499573 You'll see two files a "before" file of what it looks like before I format. And then an "after" file of what is looks like post-beautify-ing. I did notice it seems to do this in a .js file too. But those lines aren't very long, so I don't think it's a line length issue anymore...
The js file I saw it happen in is also a React component written in ES6 with jsx in it as well...