Updating Packages


#1

im creating this topic only to advice that im updating some package that i use in atom but they not are updated for some reason.

Well, i don’t publish this packages because the im not the original author, i only update the extension to not show deprecations in atom and trying to optimize some code.

Until now i update this two packages:
LiveReload
Less Autocompile

If u are thinking why i don’t send a pull request to the authors, well i send it but seems like they are busy or doesn’t have time to work on this (they can have his reasons and i respect that), i only want try to help to get Atom better and packages better.

Ps: Sorry for my english not is my native language.


#2

Awesome! I also wanted to bring less-autocompile up to date, but couldn’t find the time… I used it as a base for my stylus-autocompile and coffee-autocompile packages. Thanks :smile:


#3

actually i want make some modifications in less-autocompile to support more than only one main file.


#4

Hmm… Interesting! I’ll be watching the repository for changes


#5

@olmokramer i added the option to put more than one file in the main option only put this char “|” between files to separated, u can check out in my repo


#6

I think it’s commendable that you’re improving stale packages. However I would urge you to reconsider two things.

Sending in a pull request does help those authors out. It’s just a button click away and if your fork is better it’s easy for them to merge it. And it makes it clear for everyone who didn’t read this post that improvements are out there, including the original authors.

Also, please do publish your efforts. You’re not stealing anything, and again, how else is anyone going to know that an updated version of a feature is available?

I recently forked Zen and published that. The fork got some feedback, allowing me to improve it further. In the end I was able to work with the original author and upstream the whole thing.

That’s how open source should work, it get better if everyone not just shares their hack but tries to work with the github system. And some repo will go stale but if no one publishes the new repo nothing will happen.


#7

That’s cool! I’ll check it out and update my packages


#8

Yes u are right, i will think about publishing this package.


#9

I was thinking: The less-autocompile package seems to be quite popular, next to autocompile-less there’s now also a coffee, a stylus, and a sass variant. It would be nice if there was one package - let’s call it autocompile - that provides the autocompilation as a service that other packages could consume. That way the other packages would only have to provide the actual compilation function to the autocompile package. Any thoughts?

Edit: The packages would also have to supply the comment style for that language, and indicate if they can start with a shebang (#!<command> as the first line in the file)


#10

Yes i think the same when i see ur packages actually i think that we can do that only with the extension of the files if the extension is .styl we use the stylus compiler, for extension .less use less compiler… but we have a lot possibilities then i stop to think we can get a lot compilers in one place but not all people needed and maybe the package will get more heavy (i don’t know, will have to try it to see) but maybe if only put the styles compilers can be something good.


#11

What I thought was have a single package that provides just the autocompile mechanism through ServiceHub, entirely language-agnostic - again I’ll call this autocompile. Then other packages (less-autocompile, coffee-autocompile etc.) could consume the service provided by autocompile and provide their specific compilation implementation. Kind of like how autocomplete-plus works with its suggestion providers.


#12

uh is a nice approach i like kinda understand u i need read more about that to see.

Is like the package linter work right?


#13

That was my general idea, yes. But linter doesn’t use the ServiceHub which I think was built for inter-package communication in Atom


#14

is a good idea i like it i will read more about that ServiceHub


#15

Recently I was looking for that too and found 1 issue and 1 PR regarding support of the service API in the linter package:

None of them seems to have any activity recently so I wonder if the linter will use the service API soon. It’s a bit sad given that it would open a lot of cool things (I was going to add a minimap plugin to display linter errors in the minimap, but that’s seems compromised).


#16

Also, maybe we can move away from checking the file’s extension in favor of the scope that atom provides?


#17

That’s too bad… Would love that minimap plugin :smile:


#18

Well only to say that i publish a package less-compiler like an alternative to less-autocompiler.


#19

Have you seen the changes in the upstream repo? Some quite interesting stuff. It does away with the panel and uses atom’s notifications, and it adds support for sourcemaps


#20

Yes i see!, i like it too.

I get some ideas from the new version of him and merge with my ideas. i get down the load time from 47ms that i have before to less than 5ms now using notifications.

in the next version i will add support sourcemaps but i want to see what more i can do to get better this or maybe add support for other stuff like the ServiceHub or integrate others compilers.