We Keep Coding

JavaScript, Reading and Writing files for a locally hosted application

I have read several posts on this site that ask similar questions but the key difference is they involve a client and a server. For my use, this is not the case. I am simply pasting a file directory on my computer into my browser in order to view a local HTML file, packed with CSS and some jQuery.
I've been looking around and the answers I've found are "No; a client can not write to a server", and "No; a server can not write to a client". But there is no answer to "can a client write to a client with JavaScript?"
Use case:
I'm building a webapp (website? JS app?) as a college project for a stock management tool that will be locally hosted and never connect to the internet. Sure, I could knock one together in python in a couple hours, but I wouldn't learn anything. I need to create an access a txt file containing an array of the current stock of all the items so that when the application is loaded, the user doesn't have to manually enter anything but the changes to stock levels.
Honestly, I'm a beginner at JS and JQ and I'm only going off of what makes sense based on a mix of HTML and Python that I know.
Maybe PHP would be the better option for this particular option, or maybe JS will work well enough.

You still won't be doing client-to-client, your browser will just act as though the local file system is the server using the file:// protocol which means the same rules about a "client" (the browser) cannot write to a "server" (your local file system) apply.
If you wan't to be able to write an application that can interface directly with the filesystem, then look into something like Electron which is essentially an augmented website that gives you APIs to interact with the actual computer the app is being run on, including filesystem stuff.

Hiding React Src From User Until Logged In

So I noticed when I ran my react app's production build's login screen from create-react-app that all of the source code for the app was available within the static/js folder. Basically, the code doesn't look any different from the code in my ide, on the production build.
I am wondering if there is a way to hide this behind a login screen? So that a user can't directly access these files unless the login is successful. I have looked around and was unable to find anything of use.

The js files from the production build should be minimized which would look a lot different than in your IDE. I assume what looks "the same" is looking at the source using developer tools. The solution for that is to not deploy the source map files (*.js.map). Those are the files that allow developer tools to transform the minimized code back to its original look.
Removing source maps makes it difficult for someone to learn from the code easily, but if there is sufficient motivation to do so, it can still certainly be reverse-engineered. There are also some parts that wouldn't be obfuscated much at all such as the URLs for API calls which would then give someone a lot more information to use as the basis for hacking attempts.
If you need to prevent seeing any version of the source for people that are not logged in, I would recommend building your app as two apps -- one that just contains the login portion and one with the rest. Code-splitting within one app won't do the trick (at least not without using a solution that is quite a bit more complicated to manage than the two-app option), because it just makes the download process lazy and it is still pretty easy for someone to determine what the other files are and download them. However, even splitting this into two apps only helps if you host the second app differently. This will require server-side protection that only serves the JavaScript files for the second app for a user that is logged in. This means either using a different sub-domain for the second app or at least a different directory on the server that has those protections baked in. How you would implement that protection depends on the details of your authentication approach and the technology stack being used on the server. Most likely, it means using a cookie set by the login process and then having the JS files for the second app served up by something that verifies the cookie before allowing the JS files to be served to the browser.

To overcome displaying your source code in production's build, try to build your app with
GENERATE_SOURCEMAP=false npm run build

AngularJS & PHP: upload my app on several servers after changes

I develop an angular-php web application which I have it running online, for different users, on 5 different subdomains, such us:
sub1.mydomain.com
sub2.mydomain.com
sub3.mydomain.com
sub4.mydomain.com
sub5.mydomain.com
Problem:
My problem is that I still develop the web-app local and whenever I change files(php, js,tpl.html,css or when add new ones) I have to upload them on each subdomain.
Question:
Is there a way/library/API whatever that I can use to make something like package (with the updated or new files) and just call it from each subdomain url , and make the appropriate updates?
Or should I just copy them to each subdomain?
Do I make myself clear, in other words just like on cms systems that we press the update button and we update a component/module.
If anyone knows a way of doing that please enlight me. Thanks.
I tried to depict what i mean.

What you are describing is called deployment.
There are a lot of ways to create a deployment mechanism so there is not a single answer to your question. Depends of the tools that you are using, the servers where your app is hosted, etc.
If not, I advise you to use Git to make versions of your app (with Github or Gitlab) and automate the deployment process when you push a new piece of code.
You can make your own scripts to deploy or use online services (surely what you need because of "systems that we press the update button").
I can't advice you one particular service but you would find what you need in Googling "deployment automation github".

I would do it with config files. Considering the code for all my substations is the same. I would have config for each sub-domain and fetch the core files from the same location but serving different data If your structure allows it.

Automated swapping out of JavaScript library URLs on deploy

I'm building a purely client side JavaScript based web app, and am looking to optimize the workflow for switching to CDN URLs for the JavaScript libraries I use on the production server.
In order to be able to do work offline, my laptop development machine loads all the libraries from a /js folder on a local web server. When I deploy the app, I want to substitute these URLs to use CDN versions of the jQuery library on Google e.g.. Since there's no server side logic, I can't make a check there for something like Rails.env.production? like I would if this were a Rails app.
I'm deploying by pushing to a git repo on the production machine and running a post-receive hook. I imagine I could run some kind of sed routine that switches URLs over the update in the same post-receive script, but am curious if there's not maybe a more elegant solution.
The easiest thing would be to simply put client side logic into the app to check what hostname it was called form, but I'd like to keep that as a last resort.
There is a previous discussion on fallback loading here, but a broader sense my question is about the automated swapping out of a block of text for another when deploying to a production machine.

You want to commit the change that has the pointer to the CDN version on the branch from which you will be publishing.
Commit the change that will have the development version to your development branch.
Assuming that this is the only way your branches differ, merge with "ours" strategy on both branches.
git merge -s ours mainbranch
This will ensure that you don't get that code change from now on wherever you merge or rebase.
hope this helps.

You could simply make the CDN host work locally by adding it to your /etc/hosts.
If that's not an option, use inline JavaScript to add the <script src="..." tags to the document and put some logic to decide whether to use CDN or not into that script.

How to set different baseUrl path in jQuery ajax requests in development and production mode?

My baseUrl path for jQuery ajax requests is different in development and production mode. How can I set it in some kind of config.ini file to switch it easily. Rightnow I'm using a baseurl.js file containing just baseurl path. In production mode, I change this variable via shell script.
What should be better approach?
edit
To make things little clearer,
$.ajax({
type: "GET",
url: myurl,
dataType: "script"
});
Here 'myurl' var is different for production and development.
PS: My question is not about version control or packing files into one.

If you are using some dynamic pages technology (asp, php, ...) then you could turn your baseurl.js file to a dynamic one like baseurl.js.php and inside it print the current url . (if that is what you are asking).
for php look at $_SERVER
for asp look at Request.ServerVariables

When deploying any sites that use more than I little JavaScript, I like to use YUI Compressor to pack all of my script files down in to a single file which then gets included on the production site, and will load much faster than if the browser had to load each file individually.
To avoid making mistakes when running it, I created a shell script containing the command line arguments for YUI, which gets run before deployment. This is also the perfect place to reference any production-specific JavaScript files - for example you could create a production.js file that sets your baseurl path and include it in the command line.

Using a revision control system would be the best approach.
You would have one configuration file, and each client can "check it out" and modify it at will to suit their own environment (development, testing, production, etc).
You'll probably have the production configuration committed to your revision control system, and you'll have a customized version in your development environment. Just don't check your customized version in to the revision control server.
I don't know what operating system you're on, but I would recommend TortoiseSVN (for Windows) and Beanstalk (hosted subversion service) to get up and running with minimal effort. If you'd rather setup your own SVN server, VisualSVN makes it a trivial task.
And voila, no more swapping configurations!

I think that having relative URLs be different in development versus production sounds like a mistake anyway. That's pretty much the advantage of relative URLs: they navigate your application structure in a way that's independent of host deployment details.