How to use common dependencies in different clojurescript projects? - javascript

I wrote a clojurescript project. It is a reagent component. Now i want to use this component in other clojurescript project. That is what i do: I compiled my cljs project and then i put a result compiled file to js folder in other project. Further i require that file from index.html. At the end i invoke my component from cljs file
(.slider-view (.-views js/swipe) (clj->js [[:p "1"]
[:p "2"]
[:p "3"]]))
and it works. But i have a question. My project and project where i connect my component have common requirements. For example React and ReactDOM. How to exclude this two references from my project and then connect it from another project? Is there alternative approaches? For example require cljs namespace from another cljs project directly

Even if you could prevent JavaScript libraries from being included twice, you will still have huge chunks of the ClojureScript standard library compiled in twice. As you suggested, you will want to put your first project on the classpath of your second project (by adding it to your project.clj or equivalent) and then include that namespace directly.

Building on Justin's quite correct answer...
What you describe is exactly the normal ClojureScript dependency relationship. In this case, the dependency is something you have created, rather than someone else's existing library, but it is still the same situation.
There is one important subtlety to note. You may want to develop both of your projects simultaneously. This may seem tricky, since dependencies normally require a version number, deploying, and all the rest of the heavy lifting that is just too painful for quick development.
Fortunately, the standard ClojureScript tooling offers a solution to this, called the Leiningen checkouts directory, which works by letting you put a symlink to your dependency inside your main project's directory.
Details are in the checkout-dependencies section of the Leiningen documentation; or just web search for "Clojure checkouts", if that ever decays.
As you get further into these techniques, you may hit some more subtle problems involving the Figwheel tooling. When you reach that stage, this article may also be useful.

Related

How to find dead code in a large react project?

In order to refactor a client-side project, i'm looking for a safe way to find (and delete) unused code.
What tools do you use to find unused/dead code in large react projects? Our product has been in development for some years, and it is getting very hard to manually detect code that is no longer in use. We do however try to delete as much unused code as possible.
Suggestions for general strategies/techniques (other than specific tools) are also appreciated.
Thank you
Solution:
For node projects, run the following command in your project root:
npx unimported
If you're using flow type annotations, you need to add the --flow flag:
npx unimported --flow
Source & docs: https://github.com/smeijer/unimported
Outcome:
Background
Just like the other answers, I've tried a lot of different libraries but never had real success.
I needed to find entire files that aren't being used. Not just functions or variables. For that, I already have my linter.
I've tried deadfile, unrequired, trucker, but all without success.
After searching for over a year, there was one thing left to do. Write something myself.
unimported starts at your entry point, and follows all your import/require statements. All code files that exist in your source folder, that aren't imported, are being reported.
Note, at this moment it only scans for source files. Not for images or other assets. As those are often "imported" in other ways (through tags or via css).
Also, it will have false positives. For example; sometimes we write scripts that are meant to simplify our development process, such as build steps. Those aren't directly imported.
Also, sometimes we install peer dependencies and our code doesn't directly import those. Those will be reported.
But for me, unimported is already very useful. I've removed a dozen of files from my projects. So it's definitely worth a shot.
If you have any troubles with it, please let me know. Trough github issues, or contact me on twitter: https://twitter.com/meijer_s
Solution for Webpack: UnusedWebpackPlugin
I work on a big front-end React project (1100+ js files) and stumbled upon the same problem: how to find out which files are unused anymore?
I've tested the next tools so far:
findead
deadfile
unrequired
None of them really worked. One of the reason is that we use "not standard" imports. In additional to the regular relative paths in our imports we also use paths resolved by the webpack resolve feature which basically allows us to use neat import 'pages/something' rather than cumbersome import '../../../pages/something'.
UnusedWebpackPlugin
So here is the solution I've finally come across thanks to Liam O'Boyle (elyobo) #GitHub:
https://github.com/MatthieuLemoine/unused-webpack-plugin
It's a webpack plugin so it's gonna work only if your bundler is webpack.
I personaly find it good that you don't need to run it separately but instead it's built into your building process throwing warnings when something is not ok.
Our research topic: https://github.com/spencermountain/unrequired/issues/6
Libraries such as unrequired and deadcode only support legacy code.
In order to find the unused assets, to remove manually, you can use deadfile
library:https://m-izadmehr.github.io/deadfile/
Out of box support for ES5, ES6, React, Vue, ESM, CommonJs.
It supports import/require and even dynamic import.
It can simply find unused files, in any JS project.
Without any config, it supports ES6, React, JSX, and Vue files:
First of all, very good question, in large project coders usually try many lines of code test and at the end of result, hard to find the unused code.
There is two possible that must be work for you - i usually do whenever i need to remove and reduce the unused code into my project.
1st way WebStorm IDE:
If you're using the web-storm IDE for JS development or React JS / React Native or Vue js etc it's tell us and indicate us alote of mention with different color or red warning as unused code inside the editor
but it's not works in your particular scenario there is another way to remove the unused code .
2nd Way unrequired Library: (JSX is not supported)
The second way to remove the unused code inside the project is unrequired library you can visit here : unrequired github
another library called depcheck under NPM & github here
Just follow their appropriate method - how to use them you will fix this unused issue easily
Hopefully that helps you
I think the easiest solution for a create-react-app bootstrapped application is to use ESLint. Tried using various webpack plugins, but ran into out of memory issues with each plugin.
Use the no-unused-modules which is now a part of eslint-plugin-import.
After setting up eslint, installing eslint-plugin-import, add the following to the rules:
"rules: {
...otherRules,
"import/no-unused-modules": [1, {"unusedExports": true}]
}
My approach is an intensive use of ESlint and make it run both on IDE ad before every push.
It points out unused variables, methods, imports and so on.
Webpack (which has too nice plugins for dead code detection) take care about avoiding to bundle unimported code.
findead
With findead you can find all unused components in your project. Just install and run:
Install
npm i -g findead
Usage
findead /path/to/search
This question recalls me that react by default removes the deadcode from the src when you run the build command.
Notes:
you need to run build command only when you want to ship your app to production.

Using React with an existing application with JSX

We are planning to switch new technologies like react for my CMS project which is under development for 10 years.
Until now everything was simple and plain on the front end.
First include jquery.js then if necessary include the components and third party scripts, then code and dance with the DOM.
But now while trying to jump into a higher level of technology and different approach, things can easily get very complicated for me.
After spending more than 10 hours with React documents and tutorials I have a very good understanding about what it is and how it works.
But I realized that I am very unfamiliar with some popular concepts. I never used node.js, never used npm, babel, webpack, and may other many "new" things I have seen every where. I am face to face with these tools because of React and I am convinced that these are the inevitable for modern front end development.
Now the question
Our CMS runs on PHP and depends on MooTools heavily at the front end. Instead of a complete rewrite of a 10 years old CMS I just want to try new technologies partially for some cases. Decided to starting with React.
For the case I want to integrate ag-Grid to React also.
What I did not understand is that how to bring all these tools together.
I won't be able to use the simply include js way of react because of ag-Grid.
In the examples the code written has some JSX. Which means that we write JSX and run it translated for the browser to test if it is ok.
Each time before testing do I need to translate these files?
And more over if the files are translated does debugging become very
complicated?
Can babel make it on the run time? If yes is it a good practice.
There are lots of file in the node_modules folder. Which of them
should I include for production?
All sources on the net are very theoretical and assumes a knowledge. Need some guidance for best practices.
There are lots of questions and not a single step by step guide from beginning to production.
JSX is an extension over spec-compliant JavaScript. It is syntactic sugar for React.createElement(...) and is optional in React development.
React can be written in plain ES5:
React.createElement("div", { foo: "foo" });
Instead of JSX:
<div foo="foo" />
Or with helper functions like h that achieve the same goal, e.g. react-hyperscript.
The fact that there is PHP backend application doesn't prevent from developing React frontend application with JSX. This may require to configure React project to not use built-in Express web server and build client-side application to custom location, i.e. existing app's public folder. In case create-react-app is used, this may require to eject the project).
Each time before testing do I need to translate these files?
They should be transpiled to plain JavaScript (ES5 if it targets older browsers). They can be translated on every change in source files when client-side project runs in watch mode (conventionally npm start).
And more over if the files are translated does debugging become very
complicated?
This is what source maps are for.
Can babel make it on the run time? If yes is it a good practice.
It's possible to use Babel at runtime, and this isn't a good practice, even in development environment.
There are lots of file in the node_modules folder. Which of them
should I include for production?
The contents of node_modules doesn't matter. Almost all of them are development dependencies that are needed to build client-side app. This is the task for a bundler, which is Webpack in create-react-app template. It builds project dependencies to plain JS in dist folder.

How to structure a node cli application

I want to write a node cli application and im wondering how i should structure the application. Im fairly new to node and im a confused with all the design patterns used when building such a application.
I want to be able to call the application from the command line, but also use it as a node module for better testing.
Currently i have one file with lots of functions that get called directly from the cli, but i feel this is rather difficult to maintain.
Is there any good writing on how to do such things? i looked at rimraf but it confused me even more. Thanks for your time
I don't know if there is a "right" way to do it but I can tell you how I have dealt with a problem similar to yours. I wanted to create a CLI and a visual studio code plugin so people would be able to use the functionality both from VSC and from the CLI (for those that don't use VSC), so the approach I took was to put all the logic in its own package and then create two other packages that included the first one, one for CLI and one VSC plugin that required the "logic" package.
In the CLI package you would only have code strictly related to command handling and then the real meat happens in the logic package. In my case the VSC plugin package had very few lines of code, just configuration and the calls to the needed functions.
Then regarding the structure of the code some recommendations:
expose only what is strictly necessary
isolate your code in different files/classes based on common functionality (and go to point 1)
test your code
lint your code
But those are common sense and language independent recommendations.
There's no one "standard" way to structure Node.js apps, however you will notice that many authors follow similar patterns. Instead of having one file containing all code, it should be split out into modules, grouped by function. Have a look at this repo on Github, it has some very good suggestions about Node.js best practice https://github.com/i0natan/nodebestpractices#1-project-structure-practices.
A couple more pointers I would add: Ensure you're logging any errors, consider using something like Winston.js for this purpose. Also have some mechanism in place to restart the service if a critical error occurs, e.g. Forever.js.
Ensure likewise you're unit testing, there are some good test frameworks, Jasmine, Mocha, Cucumber.js.

Correct way to author Vue components that rely on parent build tools

I imagine this problem would apply to other frameworks that have a bit of a plugin/component ecosystem about them that rely on specific build tools (React components with JSX, etc). Vue is just my use-case.
I have authored several Vue components in the form of single .vue files which are published to NPM. The package.json for these component does not list any dependencies, as they themselves are intended to function within a parent project that uses webpack, vue-loader, sass-loader, etc. This is an example of one such component.
I am unsure about the best way to declare that these components rely on the parent package having said build tools. I am not confident that devDependencies is the correct place for them as the component itself has no development step that relies on these. peerDependencies seems more suitable but again I am not confident this properly matches what I am trying to achieve.
Looking through many of the components on the awesome-vue repository I can't see any use of peerDependencies and the devDependencies seem relevant to the development of the particular components themselves.
What is the correct way to author these components? It's almost like I need something like "peerDevDependencies".
Most component are, unfortunately distributed already compiled.
In my opinion the best way to distribute a component is to write as main the raw .vue file of the component.
You shouldn’t specify to use any particular tool, developers that pick up your package should be free to use the tool they want, be it Browserify or Rollup (or Webpack). The raw .vue format allows them to compile the .vue component with whatever tool they want and using whatever Vue version they want (within a range of course).
Moreover what I like to do is give the users the possibility to use the component straight away, even inside a browser, with just Vue as a <script> dependency. For this you would have to compile it and, yes, specify Vue as a peerDependency in the sense that it’s needed in the page.
You can put meta information in the package.json to tell CDN to pick up the compiled version when inside the browser, this is very handy so the user just specify the name of the package without worrying about the file name or version.
Speaking only as a consumer of Vue.js components, I think specifying your build dependencies as peerDependencies is the best solution. You are using what is a pretty standard build pipeline, but I think that having them specified is important. These are not strictly devDependencies or dependencies depending on where they are going to be compiled by the end user.
I'd suggest you use "module" property on the package.json for the raw vue file, and the "main" as the compiled one. module is a property getting standardized and webpack and rollup already understand it.
For more info see setting up multiplatform npm packages article.

How can I structure/access the react components of my non node.js application?

I have a production application whose folder structure is much like you would expect:
/project
/css
/js
/php
/fonts
/images
/index.php
I have recently begun learning to use react.js and I would like to start developing new features using react while leaving all existing functionality as is and I understand that react.js can certainly be used this way.
What isn't entirely clear, is how to structure the files in my non node.js project and access them.
For example, I tried searching for this and found this article which proposes the following structure
and states:
Here index.jsx works as the entry point of the application. It uses ReactDOM.render to render App and gets the party started. App in turn does something interesting with Note. If I wanted yet another component, you would simply add it below /components.
Presumably this is a node.js project where index.jsx can call something like require('components/App.jsx');, but how do I achieve the same in my non node.js project.
Consider if I set the following folder structure:
/project
/css
/js
/php
/fonts
/images
/react
/components
/App.jsx
/Note.jsx
/scripts
/featureFoo.jsx
/index.php
Given the above, I'd like to have index.php load react/scripts/featureFoo.jsx which would somehow include/use react/components/App.jsx and react/components/Note.jsx
I figure I could have script tags in index.php to load all of the components then featureFoo.jsx but I feel like there is a more react way to do this.
So
How can I structure/access the react components of my non node.js application?
Im tagging node.js as I feel those users may well bring insight regarding this possibly from having to deal with multiple projects/aproaches.
In order to import/require other modules in a non-node.js (i.e. browser-based) JS application, you'll need to use a bundler such as webpack or browserify.
They work by starting at your "entry" file (index.jsx in your case) and recursively following all of your imports/requires. Then it smartly bundles everything up into a single "output" file, which includes everything your application uses, that you can link in your HTML.
You can also use more complex configurations with multiple entry and output files, or even dynamic loading of "chunks" at certain points in your application. But the above is the most basic use case, and works well for most simpler projects.
These bundlers have some other cool features as well. For instance, with webpack (with additional plugins and loaders) you can:
Write ES6/ES7 JavaScript that gets compiled (via babel) into cross-browser compatible ES5
minify/uglify your output JS
import/require non-js files such as CSS, images, and webfonts, and choose how to process these imports (e.g. pre/post-process your CSS, or optimize your images)
Extract all imported CSS into a single .css file
Use webpack-dev-server (or webpack-dev-middleware) to take advantage of hot module replacement, which makes developing JS apps easier by letting you see your changes take effect instantly in the browser without having to refresh or lose your app's state.
And a lot more. The world of bundlers is a pretty big ecosystem with a lot to learn, but it's totally worth getting into.
A good place to get started is the excellent Survive JS series of tutorials.
However, if you're still learning React, then diving into webpack and the entire ecosystem of JavaScript tooling can be overwhelming. It will probably be easier and a more efficient use of your time to keep things simple at first, and then only get into bundlers etc. after you get comfortable with React.

Categories