Currently my app structure looks like this-
.meteor/
client/
... public files
server/
typings/
tsconfig.json
And when I run meteor with the meteor command it serves my project from this directory. So client files are accessed via client/assets/images/myimg.png. Not only is the client portion redundant but It seems like a security issue as I'm then assuming server/* is also accessible. How can I update meteor so the web root begins at client/ ?
I did try google first. I either couldn't find anything or didn't understand what I was reading.
Thank you!
The convention for storing public assets (e.g. an image) is to put them in the root level folder public. If you put image.png in the public folder, it will be accessible at /image.png. You'll also want to look into using a router to appropriately serve your routes/assets.
Related
I am building a NodeJS application and I am not sure where I should compile my Javascript to (i.e. minified and uglified Javascript) and how to structure my app.
All the examples I have found online say to simply make a /public directory and put all the JS in there.
The problem with that is that even if I serve the Javascript file app.min.js from /public/js, it is still really easy for someone to figure out that at public/js/app.js he can find all my original javascript code and steal it.
What is the proper way to structure the app so I can separate development files and distribution files?
You put your public JS files in a directory that your node.js server serves up to the public and you put your private source files somewhere else that your node.js server does NOT give any access to the public.
Simply don't put private files that you don't intend to share anywhere in the same hierarchy as your public files that your node.js has routes configured to serve.
Remember, your node.js server ONLY serves files or directories that you have explicit routes for. So, just make sure the private files are somewhere other than those directories containing publicly served files.
There are lots of different ways to structure it (and none is any more "right" than any other as it depends upon what else you have in your file structure). For a simple system, I create a specific "public" directory below my server and I put all public stuff off of that. I can then use express.static() routes for the public hierarchy and nothing private ever gets shared.
I have a folder structure for a Node.js /w Angular.js project with some files like so (from project root):
frontend
frontend-file1.ts
frontend-file2.ts
backend
backend-file1.ts
backend-file2.ts
I use a TypeScript compiler along with many other gulp plugins to compile this into a build folder like so (notice how frontend files get placed into public):
build
backend-file1.js
backend-file2.js
public
frontend-file1.js
frontend-file2.js
In the source folders, I use ES6/TypeScript import statements to import files.
Example: backend-file1.ts
import './backend-file2';
Situation
I've written some custom utility functions that should be used by both backend and frontend. I don't want to repeat the same functions in both folders, since this is prone to errors and is double work.
I've considered creating a shared folder at the project root amongs the frontend and backend folders, but I can't import files in the browser that go up further than the index.html file, which is in the frontend folder.
Question
How would I be able to write a TypeScript file once and be able to import this file in both frontend and backend folders?
I would just structure the code like this:
- src/
- server/
- client/
- shared/
You can place all your shared libraries into shared directory then import/require them from your server or client source files:
import '../shared/library'
To extend the already given answer for outFile case I will show my way of dealing with class sharing in case when you cant or do not want to use webpack/browserify/outFile options.
The structure looks similar
-client
index.html
app.ts
-server
service.ts
-common
helper.ts
-dist
-client
-index.html
-lib
-client
app.js
-common
helper.js
-server
service.js
-common
helper.js
The idea is how you build the dist folder with the results of your build. I do this with gulp tasks and by having the structure above it allows me to reuse components both server and client side from the common library.
Note. To work at client side do not forget to setup base url for systemjs in index.html:
System.config({
baseURL: './lib'
});
System.defaultJSExtensions = true;
Hope this helps.
I wanted to share what I've done so that others have the same option. I felt the other options which are cleaner required a lot more work, and since this is a personal project I set it up in a simpler but more crude way.
Basically I wanted to use symlinks so that I could edit it from either location without issue and without making too many changes to the current project structure. I'm also lucky that I don't need to support Windows for this.
I already had a single repo with a React app in the fe folder and the backend server in be, both using TypeScript. Here's my resulting folder setup:
be/
src/
shared -> ../../fe/src/shared
fe/
src/
shared/
I'll note that React does not support symlinks (IIRC it's because webpack does not support symlinks) and so the "real" folder should be in the frontend.
I also wanted this to work without manual setup, and so I made an extra script in package.json which makes sure the symlink is already set up. It also creates a broken symlink if the symlink is already there, but again, this is for a personal project and I'm okay with it. (Happy to update it if someone has a better understanding of ln than I do.) In the backend's package.json:
"prebuild": "ln -f -s ../../fe/src/shared src/shared",
"build": "tsc",
I have a jquery library in my project but need to put it in linux /usr/share/js directory and not inside of my project directory.
Is there a way to do a linking in the index.html?
Including in the index.html:
<script src="/usr/share/js/jquery.min.js"></script>
doesn't help, as it looks into my working dir and I don't have a 'usr' dir
/usr/share is in the root directory and not in my working one. I don't use any php or the stuff, is there a simple way to solve this?
You need to back out of the file you are currently in by using the ../ command which goes back one directory. Depending on how many files deep the index.html file is in your project, you may need more then one like so:
<script src="../../../../usr/share/js/jquery.min.js"></script>
This will direct you 4 files out of where your index.html file is located, you may need more or less depending just do some searching through your directories and adjust accordingly.
You can create symlinks for files like this, to allow access to serve from not your document root.
The web server is also needs to be configured to follow symlinks when serving.
More info for Apache:
http://httpd.apache.org/docs/2.4/urlmapping.html
I have a meteor.js project directory (created from meteor create projectName) and I have some regular node.js .js files related to this site that only needs to be run using node fileName.js or using forver.
Is there a way to store these .js files within the Meteor project directory without it being auto-run (like how it will be executed if placed in the /server directory)?
And is it more advisable to place these .js files outside of the Meteor project directory?
Taking a look at the meteor documentation, you could probably use the private folder. This should stop auto-execution as well.
http://docs.meteor.com/#/full/structuringyourapp
private: All files inside a top-level directory called private are only accessible from server code and can be loaded via the Assets API. This can be used for private data files and any files that are in your project directory that you don't want to be accessible from the outside.
I have a private library module mylib and an app that uses the library myapp.
When I deploy myapp, I have to include mylib in the node_modules folder so it gets uploaded as well.
But each time I make changes to mylib, I have to go to myapp and run npm install ~/mypath/mylib, which takes so much time, is there a faster way of dealing with private modules?
I think you might use some of CI services. E.g. http://jenkins-ci.org/ .
And you'll be able to set up necessary operations to run on your server after every push to your working git branch (or after private module modification).
Can't you create a symlink in your application folder to your own lib?
I know this works:
Have a root folder (f.ex. "application")
Have a "lib" folder in the root folder
Have a filesystem link to your private library in that lib folder
The downside is, that you can't access your library without a path, you need to give the path like f.ex. "require('../lib/mylib/xy')", but maybe you find this worth it.