I've been experimenting with serverless lately, and I would like to add some node packages to my project. I'm currently using the aws-nodejs-typescript template.
I add packages using npm install, and then import them into my handler functions. They seem to be working ok at that point, vs code is able to pick up on the typings. When I come to deploy the project however webpack appears unable to resolve them. Im tearing my hair out wondering why it's having such trouble when as far as I can tell this is the normal way add packages in node.
The added packages appear in the package.json file as normal dependencies just like the ones from the template, but the ones from the template work and the added ones don't.
How do you add npm packages to serverless projects?
Related
I run into this problem pretty frequently while developing react applications. The latest is hwid. I am using yarn to manage dependencies.
I added the module using
yarn add hwid
It added it to the package.json file and gave me no errors. When I run the application, it says it is unable to find the module. The module is there in node_modules and everything seems to be correct and in place. So I tried deleting node_modules and running yarn install. I've done this several times. I tried force cleaning the npm cache. I have run yarn remove and yarn add several times.
I am using the WebStorm IDE. It gives me no errors, and in fact, if I let it resolve the import, it finds it just fine. This seems to only happen to me in react projects. I think, but I'm not sure, that it is usually typescript modules that give me problems.
Is there a magic bullet for this? The module is a pretty critical part of my app, so if I can't resolve it using node and react's import system, I'm going to have to just copy the files into my project. I would really rather not do that for obvious reasons.
Any help is appreciated.
If it's about typescript modules, have you tries also installing types of that modulea?
E.g.yarn add #types/hwid
I was sent a "trial project" by a company looking to hire. It's a simple project but uses Amplify and AWS. The CTO told me I need to have a certain version of Node (10.18.1 or 10.19.0) and that I should run yarn install and everything will be good to go. So I completely uninstalled Node, installed NVM and the version of node I'm supposed to use. Then I opened the project and ran yarn install.
When I open the project in browser I am apparently a module, ./aws-exports, among other files that seem to be related to Amplify and AWS. I've noticed that most of these files are in the gitignore. But again, the CTO told me that I shouldn't have to do any setup.
I've tried installing with Npm instead. Using different versions of node. All sorts of silly little fixes and I'm just totally lost.
The file ./aws-exports will be created after the initialisation of Amplify
(https://aws-amplify.github.io/docs/cli-toolchain/quickstart?sdk=js#the-init-process)
It is in .gitignore because it contains configurations information of the AWS account, which you have configured in your terminal.
Does the project have a README? If so, read that. If not, don't work there.
Google the missing package name. If you find nothing, it is likely a private package.
A quick Google search gets me this: https://bit.dev/bondz/react-epic-spinners/orbit-spinner
And this: https://docs.bit.dev/docs/installing-components#configuring-bit-registry
Use Google.
I've got quite some experience in (web) development (Java, ASP.NET and PHP amongst all), and fairly new to React and Node JS.
Although I did multiple tutorials and read multiple articles, I feel like I'm missing some point here and there. Currently I'm working on a React app which implements a nice HTML template I found.
One React tutorial I did used Webpack for building and deploying the app (local). This works nice, does the job of transpiling ES6 (.jsx) and SASS using babel. So far so good :)
My template has an image slider (Owl Carousel), so I installed the react-owl-carousel module.
This gave me quite some problems with jQuery (also installed as a module).
After several attempts to fix this I decided to move on to another slider module, React Awesome slider.
I used the module as the README.md explained. But upon building it (npm run build), I got an error that the .scss file within react-awesome-slider could not be transpiled. A message like "are you missing a loader".
So I installed sass, node-sass, sass-loader etc etc and configured these in my webpack.config.js.
I also noticed the react-awesome-slider module within node-modules contained a webpack.config.js.
Long story so far, sorry, now to the essence of this question.
In what way can the modules installed (like react-awesome-slider) be considered "black boxes"?
It doesn't feel logical that all the modules get build when building the main app. The "exclude: /node_modules/," config in webpack.config.js prevents this, not?
So why does the react-awesome-slider give an error about .scss transpiling? I had no .scss rule in my webpack config then.
Will all dependend modules automatically get installed when installing a new module? So when I run "npm i react-awesome-slider --save-dev", will its dependencies also be installed? Or is this not necessary? And do I need to update (webpack) configuration after installing a new module? Or is it really black box and "self-containing"?
Any help would greatly be appreciated!!! Maybe there is a good react-webpack sample app on Github or something like that?
That also confusing me for a really long time. Here are some answers to your question.
people publish packages to the NPM, so a module your project depends on
can be pre-builded or source code, it depends. I have checked react-awesome-slider, it's main field in package.json is dist/index.js, directly import it won't cause an issue because there are no SCSS files.If you follow the CSS module usage instruction you have import react-awesome-slider/src/styles and you will find src/styles.js file import ../styled.scss,so webpack will load it with SCSS loader which you have not configured, that's why an error occurred.
while you install modules, npm will go
through its dependency tree, install its dependencies, dependencies'
dependencies, until there's no more dependency module to install. before npm 3.0 the node_module folder is tree structure reflects the dependency tree, but it causes problems that many modules relay on the same dependency, npm will download and save too many same files, after version 3.0 it becomes flat(release note here, search flat keyword).
You don't need to update your webpack config after you install a dependency cause webpack build process will handle it with file dependency tree. You have installed a package and import it in your activation code, file there will be handle( with its package.json main field file as an entry), you have installed a package without using it or import it in a dead file(dead file means you cannot find it from webpack entry file), it will be ignored by webpack as it's dead code.
I have too many confuse until I read npm docs. Good luck to you.
Node modules are build to execute packages.When the are compiled they have proper configuration to handle extensions that are imported in it and when you import something like .scss in your main app then it does not know about that extension then your webpack need rules to include that extensions.
It does exclude node_modules as the are pre-converted pr pre build.
More over webpack is bit tough so developers create CRA Have look at it.
I'm bundling a bunch of components I regularly use in apps I create with Next.js into an npm package to make it easier to reuse them between projects, however I'm having difficulty getting it to work.
The big issue I have is that some of my components need to import/require a configuration file from the project root directory (e.g. project/node_modules/mypackage/index.[js/jsx/tsx] needs to import/require project/config.[js/ts]) so I need to ensure the app is able to import components from the npm package, and the npm package is able to import/require from the app.
I use Typescript to compile the npm package (no Webpack or Babel) but I'm not sure what settings to use for target, lib, module and jsx, or if I'm able to just keep it uncompiled as .tsx and .ts files (I'm using the canary branch of Next.js which has built-in Typescript support).
I can't find any information in the documentation, here on SO or via Google search. Any advice?
I would like to have repository with default NPM modules and its configs for all future NPM projects.
For now the configs consists of tsconfig.json, tslint.json, .prettierrc.
The goal is to have a simple way for creating new project with custom defaults and also have possibility of changing configs for all of these projects from one place.
I tried to create my own NPM module with package.json containing dependencies I want to have in all my new projects and its configs in root. The problem is obvious - if I install this package into new project, modules (and configs) are scoped to my custom module and not to my newly created project.
Does anyone has any idea how to deal with this?
You are basically making a boilerplate. Do develop it, I see two possible approcches:
Publish the boilerplate as NPM module.
Build and publish the boilerplate on your repository provider (Github, Bitbucket etc) and use it as starting project to be forked for every new project you build.
I will suggest you to follow the second approach, that's easier to achieve.
You are instead tryng to follow the first approch that's more tricky. To generate a starting project you should build a CLI (Command line interface). So you will build an NPM module that should be globally installed and that you will use with a set of commands like:
myawesomecli generate my-new-starting-project
And the myawesomecli module will generate a my-new-starting-project folder containing your boilerplate. You could optionally ask to the user for settings to be selected in an interactive session. That's what famous framework like React, Vue.js, Angular etc. are doing.
You can follow this tutorial to build a CLI that generates boilerplates. Keep in mind that the inquier module is the key module for such scopes.