Why is main.js defined in two locations in the BoilerplateJS project? It appears that only the one defined in the project's root directory is used and the one in the app directory is not. Could someone please clarify. Thanks in advance.
I had the same thought and figure other people would too. The main.js in the top level is used. The duplicate I think you're referring to inside the app sub-directory (app/main.js) doesn't appear to be used and is probably a left-over from development. In that same directory is app/application.js which is largely the same and what is kicked off from the parent main.js.
Related
Context:
I have an express web server which I'm using as a sort of 'template' to create solutions for customers. The needs and use-cases of customers in the industry I work in are all somewhat similar, and therefore most static resources (images, es6 modules etc.) are shared between them. These are all in the root /static/ folder. There are cases where the customers needs necessitate individualized scripts and resources in which case I place them under their respective solution folder, e.g. solutions/solutionA/static/def.js for customer A. In server.js, the express launcher script, I set two static directories through middleware. /static (for shared stuff), and /solutions/ACTIVE SOLUTION/static (for solution specific stuff), where ACTIVE SOLUTION is a constant string specified at the top of the file.
node_modules/
static/
abc.js
solutions/
solutionA/
static/
def.ts
solutionB/
static/
ghi.ts
solutionC/
static/
server.ts
tsconfig.json
Problem:
My problem lies with typescript complaining about es6 import statements. From within say solutions/solutionA/static/def.ts, I cannot do
import abc from "./abc.js"
even though this is correct in-browser, as I have set the root /static as a static folder.
Is there any way I can indicate to typescript via tsconfig.json or other means, that I would like it to also search in a particular directory for said files (in this case, the root /static?). I do not want the resulting js files to have their import paths changed, as /abc.js will indeed be valid due to the express middleware.
Current situation:
As the imports are correct when loaded in browser, my solution is currently "working". The issue lies in the fact both visual studio code and tsc rightfully complain of the incorrect import path. This is a fairly recent refactoring, the merging of like solutions to stop splintering. It seemed like a good idea, only now my entire project is littered with errors.... Other people are going to be working on my solution eventually, and I don't want to give them something with copious amounts of worrying warnings.
I am very new to vue and I have followed some guideline to use it.
In the first, that is here the project was structure in this way:
1) There is a src directory, and inside I have : assets,components,route,services and view.
2) There is also a server directory and inside I have : src and models directory.
But, In another guide, this one I found this skeleton:
1) There is only a src directory.
Which is the best way and Why is better to use one of this structure?
Thank you
The recommended way is for you to create a project with Vue CLI, which will end up creating the structure you mentioned first.
In a very simple project you can put all just into a simple src directory, but that is off topic here on Stackoverflow, because it is an opinion; there is no such thing as a single correct directory structure.
Don't get hung up on this. If you are new, and you're not aware of having special requirements, start with the templates in vue cli. They are a good common standard. If/when you want to branch out, do so for a reason. Here are some good project templates with various specialisations (enterprise, OAuth, etc)
I am rereading this tutorial
https://devcenter.heroku.com/articles/getting-started-with-nodejs#introduction
to polish my understanding of Node.js/Heroku.
There is a section called Define a Procfile.
But when I go to see my own apps to check what is inside this file.
I see that a number of apps (not all) have no such a file and are working fine.
So, what is going on? When is Procfile necessary? What happens if there is none?
When is it better to have one?
To help you get started, Heroku will try to automatically detect the type of your app and start it appropriately, even when it doesn't have a Profile (see example here - http://blog.taylorrf.com/blog/2014/12/15/heroku-default-server/ ).
For example in Node, if you have an index.js file and a package.json file, it's probably a node app that could be started with node index.js.
While convenient, this is considered bad practice, because:
Heroku may change how they auto detect apps in the future, breaking your deployment.
You might be missing out on some configurations / optimizations by doing so (see article linked above).
I look at many projects on Github to learn through the examples, but one thing that confuses me is when you have a package that is multiple directories deep and has webpack.config.js files in multiple levels of the directory tree.
From my understanding webpack is bundling up all the js code and making it watchable. I don't understand how multiple bundlings would work out.
For example https://github.com/ojame/react-scrollbars
On the top level you have a package.json and a webpack.config.js(So I think oh this is where I run npm install and then webpack)
But I want to see the examples in the "examples" directory and there is another webpack.config.js, which is confusing to my webpack newbie brain.
What's up with this? Where do I do my bundling to check out this resource? Maybe using the example above would illustrate the solution well.
Examples often behave like their own repository. They show how you, as a consumer, would use the package. Because you would have your own webpack config, so do the examples.
I am starting a new project in which the idea is to organize the project file/folder structure in to different modules (.csproj) and finally once deployed these modules would be loaded to one AppHost of MainModule (these sub modules would act as plugins).
However, for better physical file management (SVN/VCS) and effective organization of my project files these modules would be maintained as separate projects in SVN too. Thought is to have views, assets etc. specific to each module in its own module directory scope. (Refer screenshot).
Main Module
SubModuleOne
Views
ModuleOneDefault.cshtml
SubModuleTwo
Views
ModuleTwoDefault.cshtml
Views
Shared
_Layout.cshtml
Hello.cshtml
Module specific files would be copied as post build action into root project path rather than /Views directly (if copied then it messes up with Main module's Views folder).
Problem is with how ServiceStack loads and handles Razor views from /Views folder and anything outside is considered to be content pages. More about this, explained here...!
With VirtualFileSystem in place I was thinking aloud to maintain module specific views in respective "/ModuleOne/Views/" folder but outside the root "/Views". Somehow, this doesn't seem to work, trying to seek help on how this could be achieved or handled appropriately.
PS: Am aware that anything outside Views folder is content pages, however the idea is still to maintain as Views folder but in different hierarchy - Hoping that ServiceStack Razor feature anyway handles nested (DEEP) structure well but within root /Views folder and not from the entire Project Root folder i.e. "/".
Question is, can this be achieved as is by default without any heavy lifting? or Should I be having custom VirtualPathProvider implementation etc.?
Opinion and thoughts are greatly appreciated!
Thanks!
All Razor Views must be in the /Views folder but otherwise they can be any hierarchy as any levels of nesting doesn't affect how they're resolved, they just need to be uniquely named, e.g:
/Views
/SubModuleOne
ModuleOneDefault.cshtml
/SubModuleTwo
ModuleTwoDefault.cshtml
/Shared
_Layout.cshtml