Best practices for maintaining javascript libraries in repositories? - javascript

When developing javascript code, what are the best practices for maintaining the code in repositories?
For example, suppose I develop a set of useful functions and put them in a script called "sugar.js". In the code repository I put them in c:/codebase/suger.js.
Now I want to use the script in a web site being developed and I locate it at c:\mywebsite\sugar.js (ready for uploading to a server)
Do I keep a copy of sugar.js? What if I fix sugar.js in one location - it won't be synchronized with the other?
What if I build a second web site that also uses sugar.js? Do I take another copy located at, say, c:\mywebsite2\sugar.js?

If you are using something like visual studio, you can use NuGet for versioning many of the popular javascript frameworks on a per-project basis.
If you are writing in something else, you could try package managers such as npmjs or http://jspkg.com/JSPkg.
If it is your own library, I would recommend setting up source control and having versioned releases as branches or tags, that way you can keep track of everything. Git and GitHub support this type of thing, and you can set it up to have each version as a zipped download.
I would also try to keep each project's javascript files separate, that way any changes won't immediately break every site, just the one you recently updated. This advice could go out the window if you are running hundreds of sites and really just need a CDN.

Related

How to deminify next.js html from internet

I'm trying to rebuild a website that I scraped from the web using wget. It appears to be a next js application, as I see the _next folder. I have 0 experience in nextjs and have no idea what the inner workings are, but it seems like it is somehow minifying all the code into a single script.
Is there any way to "undo" this and make it look like pretty HTML?
Here is what it looks like
Unfortunately this isn't possible, as the HTML you scraped is pre-rendered static HTML by NextJS that's later hydrated by the JavaScript, which resides in the chunks folder.
To recreate the website, you'll first have to recreate all the JavaScript that was transpiled into chunks by WebPack or SWC, which is no easy task. It's laborious and can only be minimally automated, and there's no way to "demangle" code that's been transpiled back into its original form.
There might be a better solution to your question if you provide more information about your target and motivation behind doing so. Otherwise, I'd strongly recommend not spending time trying to reverse transpiled code.

Javascript code

I checked some websites source code and JavaScript games. The problem is that everything is readable and understandable except for JavaScript code that is isolated on a file with the extension .js. It looks like this:
{Vargas=void0,h=!0,Ge=null,l=!1,AA=component,BA=Infinity,ca=set Timeout,DA=is Nan,m=Math,ea=deconstructionism;function He(a,b){return a.on-load=b}function IE(a,b){return a.on error=b}function ha(a,b) {return a.name=b}
As you can see, it's hard to read this code because of the stupid indentation. I tried to use Microsoft visual web developer and free JavaScript editors to organize the code, but it was all useless!
How can I make it more readable?
The best place to start is to look at other open source java script libraries/modules/plugins. You must have the original code though, because what you see in the browser is already "compiled" for the web to be small and fast.
For the client you have plenty frameworks. Look for example at the list jsfiddle uses (top-left). You can also use this tool to play with javascript without having to install anything. Search on the web for those projects (that jsfiddle uses as libraries) and look into the code.
There is also a server-side javascript library that allows you to write javascript code also for the server (also web apps, the server side of them). This is called Node.js Ceck this page to find out more. In Node.js you have almost an infinite number of open source and small modules: see the node module registry wehre you find the links also to the individual project.
In any case, you certainly need a Github account to play with other's code because most of these projects are stored on Github.

Integrating parts of a project into another project

I'm building a library, and plan to use parts (could be entire files or arbitrary lines) of other libraries in my code. Also, I would like to have fixes on the other library reflect onto my library as well.
I could just add the entire library (script tag, AMD, etc.) and use it. But I don't want to use the entire bulk of another library for my very small library. One of these libraries is Modernizr, but I'll only be using at most a dozen checks only.
I could just copy-paste the implementation from one library to mine. However, when the library I need updates, this would mean copy-paste all over again.
I read about GIT and submodules, where a subfolder could contain a sub-project. This sounds promising, where a build script could extract parts of the other library and put it into my code. However, the library could have different code structure than mine which would lead to manual editing, which defeats the purpose of some steps.
I haven't gone that deep into automation but I have had basic experience with makefiles. How would one go about in doing such integration?
It's not generally a good idea to use parts of libraries that didn't pre-package those parts for you. The correct way to do it would depend on each library and how it is meant to be made/compiled. There may also be license considerations, which will vary depending on the license of the library, some would require maintaining the license for the part of the library that you use.
[Edit]
Would it be possible to include the entire other libraries, and then use some sort of minification on your library to keep the size down?

Loading local files via jQuery (part 2)

Ok, here we discussed the essence of the problem: in some browsers like Chrome and Opera HttpRequests to local files is turned off by default.
Now the question is: how to build such HTML+javascript viewer of HTML documents, that:
would run locally on any (or most of) browser(s) without additional tuning;
would not use frames;
would have an ability to work with many different files(5-10k);
It can't be done in straight HTML/Javascript if you want to load files via Javascript using AJAX requests. There are good security reasons to not allow local files script access to other files on the local system (see my answer here for more details), so most browsers will not allow this without special user configuration.
So your options are:
Don't load files with Javascript, use frames or another mechanism. If, as you state in the other question, you're shipping all this on CD, you might want to consider using some sort of build system that allows you to create static files using templates and either a database or flat-file content - Jekyll is one option I know of.
Ship an executable along with the files that can either run a local webserver or run HTML files in an application context. I think Appcelerator Titanium might fit the bill.

file layout and setuptools configuration for the python bit of a multi-language library

So we're writing a full-text search framework MongoDb. MongoDB is pretty much javascript-native, so we wrote the javascript library first, and it works.
Now I'm trying to write a python framework for it, which will be partially in python, but partially use those same stored javascript functions - the javascript functions are an intrinsic part of the library. On the other hand, the javascript framework does not depend on python. since they are pretty intertwined it seems like it's worthwhile keeping them in the same repository.
I'm trying to work out a way of structuring the whole project to give the javascript and python frameworks equal status (maybe a ruby driver or whatever in the future?), but still allow the python library to install nicely.
Currently it looks like this: (simplified a little)
javascript/jstest/test1.js
javascript/mongo-fulltext/search.js
javascript/mongo-fulltext/util.js
python/docs/indext.rst
python/tests/search_test.py
python/tests/__init__.py
python/mongofulltextsearch/__init__.py
python/mongofulltextsearch/mongo_search.py
python/mongofulltextsearch/util.py
python/setup.py
I've skipped out a few files for simplicity, but you get the general idea; it' a pretty much standard python project... except that it depends critcally ona whole bunch of javascript which is stored in a sibling directory tree.
What's the preferred setup for dealing with this kind of thing when it comes to setuptools? I can work out how to use package_data etc to install data files that live inside my python project as per the setuptools docs.
The problem is if i want to use setuptools to install stuff, including the javascript files from outside the python code tree, and then also access them in a consistent way when I'm developing the python code and when it is easy_installed to someone's site.
Is that supported behaviour for setuptools? Should i be using paver or distutils2 or Distribute or something? (basic distutils is not an option; the whole reason I'm doing this is to enable requirements tracking) How should i be reading the contents of those files into python scripts?
The short answer is that none of the Python distribution tools is going to do what you want, the exact way you want it. Even if you use distutils' data_files feature, you're still going to have to have your javascript files copied into your Python project directory (i.e., somewhere under the same directory as your setup.py.)
Given that, you might as well just copy the .js files to your package (i.e. alongside mongofulltextsearch/init.py) as part of your build process, and use package_data or include_package_data=True.
(Or alternatively, you could possibly use symlinks, externals, or some such, if your revision control system supports those. I believe that when building source distributions, the Python distribution tools convert symlinks to real files. At least, you could give that a try.)

Categories

Resources