4 ms·
I completely agree. We are in 2016. If you are a front end developer and you do not have at least one terminal opened in the front end directory of your websit
by Raphmedia 11y ago
I completely agree.
We are in 2016. If you are a front end developer and you do not have at least one terminal opened in the front end directory of your website ready to run NPM or Bower and you are still managing your dependancies manually, there is something very wrong with your workflow.
- arrty88 11y agoHow would you grab the latest versions for libs easily without a package manager?
- Raphmedia 11y agoSorry, I'm not sure that I comprehend your question correctly. Are you asking me how versions of a lib are managed in the package.json of a project? All of those are valid: { "dependencies" : { "foo" : "1.0.0 - 2.9999.9999", "bar" : ">=1.0.2 <2.1.2", "baz" : ">1.0.2 <=2.3.4", "boo" : "2.0.1", "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0", "til" : "~1.2", "elf" : "~1.2.3", "two" : "2.x", "thr" : "3.3.x", "lat" : "latest" } }
- 91bananas 11y agoI think they're asking if not using npm or similar, what is the process for updating your local copy of a file/package. Which would be, go to where project is hosted, find out what version you're looking for, click until you find actual source, copy text or download file, move file from downloads to your repo, or paste in to a new file in your repo.
- deleted 11y ago[deleted]
- Alexqw85 11y agoMake works well for me... TMPDIR=$(BASEDIR)/tmp THEME=$(BASEDIR)/theme THEME_CSS=$(THEME)/css THEME_FONT=$(THEME)/fonts THEME_JS=$(THEME)/js VER_BOOTSTRAP=3.3.6 VER_FONTAWESOME=4.5.0 VER_JQUERY=2.2.1 updatedeps: $(TMPDIR) bootstrap fontawesome jquery bootstrap: curl -L -o $(TMPDIR)/bs.zip https://github.com/twbs/bootstrap/releases/download/v$(VER_BOOTSTRAP)/bootstrap-$(VER_BOOTSTRAP)-dist.zip unzip -j $(TMPDIR)/bs.zip bootstrap-*/js/bootstrap.min.js -d $(THEME_JS) unzip -j $(TMPDIR)/bs.zip bootstrap-*/css/bootstrap.min.css -d $(THEME_CSS) fontawesome: curl -L -o $(TMPDIR)/fa.zip https://fortawesome.github.io/Font-Awesome/assets/font-awesome-$(VER_FONTAWESOME).zip unzip -j $(TMPDIR)/fa.zip font-awesome-*/css/*.min.css -d $(THEME_CSS) unzip -j $(TMPDIR)/fa.zip font-awesome-*/fonts/*webfont* -d $(THEME_FONT) jquery: curl -L -o $(THEME_JS)/jquery.min.js http://code.jquery.com/jquery-$(VER_JQUERY).min.js
- gkya 11y agoThis is actually a shell script in disguise. If this is all you do with make, I suggest you make this into a shell script: <Makefile sed -E 's/.*:$//; s/\(|\)//g; s/^updatedeps:.*/mkdir -p $TMPDIR/' > update-deps.sh BASEDIR=$PWD sh ./update-deps.sh Make is for generating output from interdependent input. It can be used for minifying your JS, or compiling your CoffeeScript in to js, or your sass (but that is handled mostly by respective compilers, tho I prefer running the compiler myself) (also, I don't use coffeescript or sass, so IDK if I'm mistaken).
- arrty88 11y agoNo my point is redundant. How would one manage upgrading dependencies without using a package manager? Why would anyone advocate against a package manager, no matter what the size of the dependency is?
- 91bananas 11y agoRight? The point of a package manager that people seem to miss. You know, how it manages packages...
- techdragon 11y agoSo Bower and NPM are now basically in control of modern JavaScript development... This is exactly the sort of thing us "JS dependency problem agitators/malcontents" are unhappy about. The vicious cycle of furious evolution in JavaScript is proving "too fast for comfort" for many of us. We do not all live entirely in the JavaScript ecosystem and no longer have the capacity to keep up with it. However remains the only language we can use in the browser so we are forced to use it and as it continues to accelerate, it becomes like an uncomfortably aggressive personal trainer screaming at us to "push harder" and trying to goad us into moving quicker. We do not have the choice to use JavaScript or not, so when it feels like is it angers us. We feel the parts of the JavaScript development community that push this ever faster, have taken no one else into account and are no longer interested in being good citizens of the web in cooperation with all us other developers. We feel understandably uncomfortable with this sudden "aggressive independence" in the JavaScript community. I'm quite sure a non trivial portion of the support for WebAssembly is because we want an alternative to JavaScript that enables us to escape from this situation. Many developers I talk to are eager to see their language of choice integrated via WASM so the are no longer forced to use JavaScript and much of the desire stems from being ever more unhappy with the direction of the JavaScript community. Everyone is entitled to their opinion, so many of us are glad we will soon have a place where our opinion matters too, not only the opinions of JavaScript developers.
- qaq 11y agoUnless they are C++ developers they will have to wait for a long time :)
- techdragon 11y agoYou would think that, but as a python developer, I already know a number of projects that will be swiftly attempting to use every angle WASM gives them in order to enable lots of new ways to run Python more reliably in the browser.
- pfooti 11y agoSure, WASM will make things better, until you have to deal with library and dependency management in your WASM-llvm-deploy toolchain. I get that the javascript world moves pretty fast. On the other hand, what you seem to be saying is, "I don't understand this, _and I do not want to expend the effort to understand it_, so therefore it is bad". There's a lot of things I don't understand, and frankly don't have the time, energy, or training to understand. I leave those things to the engineers who actually worry about them. Example: I can write and optimize SQL queries, but I don't want to work on postgres internals. If you want to be a javascript developer, you should pay attention to the state of the art. FWIW: npm isn't in control of modern javascript development. You are still able to manually find new libraries, download them, add them to your assets directory, include them, and so on. This workflow never stopped working. All npm does is provide a centralized list of library versions and their locations, along with a syntax for declaring dependencies. My current project needs to do some image manipulation, so npm handles downloading and building the mmagic libraries for my development architecture. I could do this on my own, but this is just easier. If it's too hard for you, just do it the old-fashioned way. If you choose to publish a library and not provide npm/bower support because you're old-fashioned, however, don't expect wide adoption.