I have a project created with vue cli (vue --version -> 3.0.1.) It has next file structure:
|-public
|-src
| ...
|-pakage.json
I want to add server part using same package.json. It will be great to move src and public folders to client folder to have file structure like this:
|-client
| |-public
| |-src
|
|-server
|...
|-package.json
It should be very simple but I can't find exact example.
P.S.: This solution not works - I get This dependency was not found ./client/src error.
Related
Gist for my vite and tsconfigs is here.
Disclaimer: Very new to how packages and modules work. I'm a yung'un who never had to think beyond import/export. So I may have used the term "tree-shaking" too many times below.
I'm looking to move some re-used Vue components from old projects into a shared private package that I can consume through npm. I do not intend to consume it via CDN, only Vite projects. Here is the directory structure of the "package" I've come up with:
my_components
| package.json
│ vite.config.ts
│ tsconfig.json
| tsconfig.vite.json
│
└───src
│ │ index.ts
│ │
│ └───components
│ | index.ts
│ | MyButton.vue
│ | MyDropdown.vue
| | ...
| |
| └───assets
| |
| └───sass
| |
| | style.scss
| | ...
│
└───dist
│ my-lib.es.js
│ style.css
└───types
| index.d.ts
| src/MyButton.vue.d.ts
| src/MyDropdown.vue.d.ts
I am using Vite in library mode and generating es module + bundled.
The resulting build is around 1MB of CSS and 300kb of JavaScript (before gzip). The reason for this is that there a lot of one-off components that may or may not be used in the consuming project but still bring in their own unique dependencies (fullcalendar, prismjs, tiny mce, etc.). The ideal scenario is that my shared package can have a tonne of dependencies while my consuming project still only includes what it uses in its own build.
I have a few questions and doubts and gaps in knowledge about the whole process:
A. How do I make the sass variables be able to be overridden?
This is an important requirement since styling the components uniquely per project would be impossible otherwise (?).
It seems the only way to do this would be to add src/assets/sass/style.scss as an export in my package.json file. The consumer of this package would then include this file instead of the bundled/minified dist/style.css and build it themselves. This is how Bootstrap's npm package does it.
B. How do dependencies and tree-shaking work for libraries distributed like this? How is the build process changing my existing code?
B.1) I only used import/export throughout my code. Is the resulting bundled file dist/my-lib.es.js one huge module, or does it somehow manage to preserve multiple module definitions inside a single file?
This project depends on bootstrap, prismjs, quill, fullcalendar, etc. The list goes on. All of these are in my devDependencies.
B.2) Can I expect the full source of these dependencies to have been included in my bundle, or are these "tree-shaken" by Vite when building my package dist?
B.3) When I import this bundled JS inside my consuming project, is it "tree-shakeable"? If not, how do I make it so? I want to minimize what is built in the final project app to only what is used from my shared package.
C. Is there a way to distribute without building anything at all?
Since this package is only meant to be consumed by other (Vite) projects, is there a way to package everything without building a dist folder at all? In this scenario, I would publish my src folder only and the consuming project would be expected to include/import/build what they require. This should definitely minimize what goes into the final project build, right!?
C.1) If this is possible (and I haven't found any online sources about this), how would I set-up Typescript, ESLint and Vite in the consuming project to properly process the raw code?
P.S. I want it setup as a package instead of a git repository because I might delegate the shared package development to someone else later on, and an npm package is a simpler thing to consume than a git sub-repository IMO. Feel free to point out why I may be wrong in this, but please do not do so as the main solution in your answer.
D. Analyzing everything!
I imagine I would have a better grasp of the above concepts if I could analyze what is being included in builds on both levels (shared package build, and consuming project's application build). However, I currently know of no ways or tools or workflows to analyze such things (owing to my inexperience). Recommendations?
I have a CSS file that I want to upload to npm. My project's folder structure is as follows:
my-project (folder)
|
+---- css (folder)
|
+---- my-project.css
|
+---- my-project.min.css
When I try to upload my project to NPM, it asks for an entry point, where the default is set to index.js. For my case where there are only 2 files inside a folder called css, what should it be? Moreover, what is the meaning of the entry-point for an npm project?
Entry point is a JavaScript file that gets called when your module is needed.
By common practice, it is usually given the name "app.js" or "index.js" (your case).
The entry point is also the path that will be used to access your module.
CSS files cannot be entry points.
I installed GPS and ADA and stated ready a couple of books ant looking at websites on Internet.
After doing a few of exercises, I transformed a couple to a local library since they where constantly used in further chapters.
I do not see (understand?) How I can setup a local library in the project file of the exercises.
Directory structure of my test environment:
The file Test01 uses Basic_IO and Test02 uses Both Basic_IO and the generic Basic_Stack.
Here is the project file for Test01:
Can someone explain to me how to get setup the lib so the program would compile and link?
The trick is to create seperate project files (.gpr files) for Basic_IO and Basic_Stack and reference these project files (using with) in your test project files. You might want to take a look on learn.adacore.com and in the GPRbuild user’s guide. I would also change the directory structure to (something like) this:
|
+-- learning_ada.gpr
|
+-- tests/
| |
| +-- test01/
| | |
| | +-- test01.gpr
| | +-- obj/
| | +-- src/
| | |
| | +-- test01.adb
| |
| +-- test02/
| |
| +-- test02.gpr
| +-- obj/
| +-- src/
| |
| +-- test02.adb
|
+-- shared/
|
+-- basic_io/
| |
| +-- basic_io.gpr
| +-- obj/
| +-- src/
| |
| +-- basic_io.ads
| +-- basic_io.adb
|
+-- basic_stack/
|
+-- basic_stack.gpr
+-- obj/
+-- src/
|
+-- basic_stack.ads
+-- basic_stack.adb
The "library" projects could (in your case) remain quite simple. As an example, for Basic_IO, I'm pretty sure that something like
basic_io.gpr
project Basic_IO is
for Source_Dirs use ("src");
for Object_Dir use "obj";
end Basic_IO;
could already work. This project can then be referenced from test01.gpr using
test01.gpr
with "..\..\shared\basic_io\basic_io.gpr";
project Test01 is
for Source_Dirs use ("src");
for Object_Dir use "obj";
for Main use ("test01.adb");
end Test01;
First of all, your library's gpr file should specify that it is a library, for example:
library project Some_Library_Name is
for Languages use ("Ada");
for Source_Dirs use ("src");
for Library_Name use "Some_Library_Name";
for Library_Version use "1.0.0";
end Some_Library_Name;
Next, you need to add a with Some_Library.gpr statement to your client's gpr file. There are three ways to do is, in order of increasing initial complexity but also long-term utility.
Relative dir (simplest)
You can with Some_Dir/Another_Dir/library.gpr specifying the directory from the client's gpr file to the library's gprfile. If this means going up with .. that qualifies as a rather pungent code smell.
Through GPR_PROJECT_PATH
To find the gprfile specified above, gprbuild will look in the current directory of the client gprfile, and in each directory given in GPR_PROJECT_PATH. You can find more information on this method in AdaCore's own documentation of this variable.
For instance, if you had C:/ada_projects or ~/ada_projects defined, and inside that were several libraries, you might add to your client.gpr file:
with Library_One/lib1.gpr
Or if you added each individual library's own directory to GPR_PROJECT_PATH, you would omit Library_One from the above.
If in resolving the with statement there are multiple matches, compilation will fail. (Thank you, Ada!)
Note this was previously called ADA_PROJECT_PATH, which still works but is deprecated.
Alire Ada package manager (most flexible)
There are some problems with the above; it requires you to set things per-machine (or per-user) which, when you add a new developer to your team or need to set up a new computer, you will quickly run into as your projects won't compile until that is done. Next, you will run into versioning problems because you never wrote down which version of said libraries you were building against. Finally, even if you meticulously record that and inform your development team, you will still run into problems when you return to an old project after creating some new ones, and you find you want to use two different versions of the same library, which isn't possible with this approach.
Alire solves this in a similar way to Rust's cargo, python's pip, C#'s NuGet, Haskell's stackage and no doubt many others, by placing the library inside your client's directory, adding each library's root to GPR_PROJECT_PATH, building the project, and then resetting the environment again. If you have an online environment and only want to use, not publish alire package, then you don't need to know the details, you just add with Project_File.gpr (without relative directory) and run alr build instead of gprbuild.
Alire makes you record the version you want of each library, and allows for multiple versions of the same library being used in different projects, and even indirectly in the same project; i.e. library1 and library2 refer to different versions of sublibrary_foo, and your client can now include both library1 and library2; if it needs sublibrary_foo, it must include it itself or specifically include the version under library1 or library2.
AdaCore is working on support in GNATStudio (the new name for GPS 20 and beyond), in the meantime you can just run alr build from the commandline.
See the official website for more about Alire.
I am trying to add a CNAME file to a Vue.js project (vue cli tool) so that it deploys in the root folder. I am hosting with gh-pages, but cannot seem to get my gh-pages branch to contain the CNAME file correctly. My current folder structure.
|-site-folder
| |-build
| |-config
| |-dist
| |-build
| |-node-modules
| |-src
| | |-CNAME
| |-static
|-index.html
|-package.json
|-(ect..)
CNAME file needs to go in /dist folder. I now know what the /dist folder is, lol.
Here is my challenge, I need to make an ear file for a specific container. To be more specific on how this ear will be created:
This is a standard j2ee ear file, with 1 WAR in it.
The container it is deployed to will expect certain xml files (which can easily be found (somewhere) inside the source project).
Here are my obstacles
The source folder contains various container specific xml files. But, these files do not map directly to where the container expects them inside the EAR file. For example, there will be a file that this container expects to be in 'EARFILE.ear/config/connections.xml'. But this file is located (in the source) at /some/obscure/unrelated/directory. This is the case for about 5-7 files.
I cannot change the original source project layout at all.
So, how can I create the compliant EAR file that I need. There is NO plugin at this time for the container that I am using, I have certainly looked.
Update:
The original layout is for JDeveloper:
.adf
/META-INF/
(some xml files to map to various locations in the EAR)
Model
ViewController
public_html
src/
META-INF/
(some xml files to map to various locations in the EAR)
This is a standard j2ee ear file, with 1 WAR in it. The container it is deployed to will expect certain xml files (which can easily be found (somewhere) inside the source project).
As I told you in this previous answer, the typical layout for a maven project with a war and an ear module would look like this:
.
|-- ear
| |-- src
| | `-- main
| | `-- application
| | |-- META-INF
| | | `-- application.xml
| | `-- config
| | `-- connections.xml
| `-- pom.xml
|-- web
| +-- src
| `-- pom.xml
`-- pom.xml
Where the files under the ${basedir}/src/main/application directory will be included in the EAR (this is the default value of the earSourceDirectory parameter).
The source folder contains various container specific xml files. But, these files do not map directly to where the container expects them inside the EAR file. (...)
I'm sorry but... what source folder? It would be maybe possible to use the Maven AntRun plugin to copy some files to the ear project from another location but 1. that would be very messy and 2. without more details, it is impossible to provide more guidance.
I cannot change the original source project layout at all.
Which looks like? You really need to give more details (and if you can't change anything, mavenizing this project may not be easy at all, especially if you're new to maven).