I'm trying to install Sharepoint Client-side Solution using Yeoman but running into difficulties.
I can't get passed the 4th question, it doesn't accept any input so I can't answer it.
Versions
node v8.1.0
yo v2.0.0
gulp v3.9.1
microsoft/generator-sharepoint v1.3.2
Not really sure what is the issue here as it looks to be specific to your machine. I am able to get past the questions and create a solution.
However, as a workaround for your issue, you can try the below steps:
Paste the below command to see the list of command line options available for the SharePoint generator
yo #microsoft/generator-sharepoint --help
It will show up as below:
Based on that, you can create the command string and generate the project as below:
Assume that you want to create an SPFx webpart with React framework, then your command would be as below:
yo #microsoft/sharepoint --solutionName "hello-world" --framework "react" --componentType "webpart" --componentName "HelloWorld" --componentDescription "HelloWorld web part" --environment "spo" skipFeatureDeployment false
Similarly, you can create/modify the above command as per your requirements.
Reference - Scaffold projects using yeoman SharePoint generator
Also, ensure that you have enough disk space for those node modules. It will take up approx 300 MB space.
Related
I am trying to create docker image of this official public repo of keystonejs https://github.com/keystonejs/keystone
But it contains lot of packages inside it and each package contains package.json inside it, it is some short of multi-module project.
the package.json is present in root directory as well as in sub directory.
how can we create docker image containing all these packages ? if anyone has worked on keystonejs please help me on this ?
thank you
The Keystone codebase is indeed "some sort of multi-module project" – it's what's called a monorepo.
Generally, the term "monorepo" refers to a collection of source code from different projects, stored together in a single repository, inside a version control system (like git for example). They're fairly common for large projects:
Google, Facebook, Microsoft, Uber, Airbnb, and Twitter all employ very large monorepos with varying strategies to scale build systems and version control software with a large volume of code and daily changes.
— Wikipedia: Monorepos
In the NodeJS ecosystem "monorepo" often refers to a repo that includes code for multiple npm packages.
In Keystone case, the main repo includes several npm packages (in the packages dir), a bunch of tests, the Keystone marketing and docs websites (in docs), and various other bits and pieces.
Thinkmill, the team that builds Keystone, has a guide on the monorepo patterns and tools they use. A Google search will give you plenty of other takes; it's a popular topic.
How can we create docker image containing all these packages?
If you want to deploy a Keystone app using docker you don't need to mess with the Keystone repo itself. You just want to install Keystone as a dependency, like any other npm package. The steps are basically:
Create a project in your own repo
Pull the core Keystone npm package (#keystone-6/core) in as a dependancy, then..
Add a dockerfile that builds and runs the app
Getting a Keystone project running is actually super easy – it only take a few files. There's even a tool called create-keystone-app that sets them up for you. I'd suggest running thought the Getting Started guide to get a simple app running locally, then write your dockerfile there.
i will try to give you a little of context.
With my team we are trying to migrate MUI v3 to v4 in a reactJs project. We did it with the project itself and it works! but, some kind of problems came up when we navigated to certain windows that use a certain library to work.
This library was developed by other guy that is not in the company anymore and we are not in touch neither, but, we have access to the library GitHub repository, them are two actually.
https://github.com/rjpizarro/forms
https://github.com/rjpizarro/make-request
i've never had to do this so, i decided to clone the project then install the dependencies and run it.
I'm using nvm so in that moment i was working with node v12 and i got some errors when i executed the npm start ("start": "webpack --watch").
If i use node 10 the scrips runs perfectly but in the entire project we are using node 12 so i'm not sure what is the problem here.
i'm wonder if it could be a problem when i'll try to migrate from MUI v1 to v4 and use the modified library into my project again, or in first place, why its working rigth now?
Anyway i just wanted to know, just if i need it, Could i use different versions of node in a library and then use other newer version into the entire project?
Could this make some negatives effect into my entire project?
Which is the best way to migrate MUI into this library and put it in my project again?
Each nodejs process (including all the modules/libraries it loads) has exactly one version of nodejs running. It isn't possible to have two separate versions of nodejs in the same process each running different parts of the code.
You could make two separate nodejs apps that each run under a different version of nodejs that communicate with each other via some interprocess communication, but they have to be two separate applications/processes.
If you want to run everything in one process (on one version of nodejs), then you will need to test and fix all your libraries to run on that one version of nodejs.
I am trying to incorporate webhint which is a linting tool that
will help you with your site's accessibility, speed, security and more,
by checking your code for best practices and common errors.
So its installation is as follows :-
npm install hint --save-dev
npm create hintrc (creates a config file)
then I add hint to scripts in package json
"hint" : hint
I run the local server using ng serve in one cmd
And I run webhint in other cmd using
npm run hint -- http://localhost:4200
I wanted to run the ng serve/build along with npm run hint.
I tried steps on link https://webhint.io/docs/user-guide/development-flow-integration/local-server/
I also tried &&, | and concurrency but all failed.
What I want is to run both these ng serve/build and npm run hint using one command.
Any help would be appreciated.
When an angular application with multiple components is run and webhint is run, the html or json formatters show errors but line numbers are column -1 and row -1.
Most likely this is because the html of the page is generated on the client side so the line/col don't make a lot of sense as it is generated dynamically. If you tell the browser to so the pages code you only obtain the initial html, and if you go to the elements panel in the devtools line and column don't have sense there.
The errors should have the html of the element with the error and that should hopefully help you identify the template with the issue.
That said, we have plans to improve this experience but need to finish a few things first.
How does webhint traverse the code using routes or urls so I can better understand it ?
When using Chrome or jsdom we wait until the page is loaded and then analyze all the html while keeping track of all the network requests. In the case of the local we analyze all the files in the folder passed as a parameter.
npm run all and concurrency don't work for me. ng serve only keeps running.
Do you have the code somewhere so we can take a look? Enabling the concurrency should launch all tasks simultaneously. Maybe it's a question of adding a delay in webhint or something similar.
Thanks!
Starte of the art:
Popular node.js frameworks come with their own starter-kits that act as project templates, such as React comes with the starter-kit .
When user want to create a new react application, they can use the short hand npx create-react-app my-app. ... to automagically create the whole project scaffold with all baseline project files, directories, and package dependencies.
When using the starter-kit, npx resolve template variables inside the starter-kit files i.e. if package.json contains an entry {{my-application-name}}, npx will as for user input to replace the template variable with e.g. "my-first-app".
React is just one example for such a starter-kit.
Problem statement:
I would like to build my own starter-kit for my own node.js framework.
At the first glance, it seems that one just follow the convention to name my package starting with "create-" and use the template-{{vars}} at the right places.
I gave it a try and started copy&paste&replace, however npm install did not work, since unresolved template variable result in build errors.
Does somebody know a tutorial how to create your own npx starter-kit?
Do somebody know how one can build and publish a new starter kit?
yes, you can build your own npx starter by using the CLI helper packages on the npm registery
Steps for how to build your own npx starter...?
you can use args or commander to get the cli
inputs ( node argv withing the process object ) and parse it
into object so you can keep track of what the user want
based on the the previous parsed object from the CLI now you can
gather more information by using inquirer where
you can ask yes/no questions or choose one of many options.
after the user answer all the questions you now can write the logic
for creating the required starter based on the inputs of the user
you can use execa to perform process command such as git
init , git clone or any command that might comes to your own mind
you can use listr to prettify your own task lists with a
beutiful spinner
you can use chalk to print the line in the CLI with colors
and make it easier to read make the message green if it's success or red when it's failed
for more explanation on how it works together you can see this video
I'm working on including Ember into an already deployed Node/Express/EJS application. I don't want to disrupt any of the existing application behavior, but instead, want build out any additional feature to the app using Ember. The server side code for these new features has already been built, and each endpoint returns the JSON format that Ember Data expects. I've been looking into Ember App Kit and Ember-cli, but I'm not sure how to include these tools into my existing directory structure, and I'm not certain if these are in face the right tools for my use case. Does anyone have any experience with this particular use case?
For example, navigating to /foo returns the existing express route that renders an ejs template, but /bar would be an Ember route that hits the api endpoint of the same name.
Use ember-cli (ember-cli.org). It's perfect for this situation as it allows you to rapidly prototype out your ember app. It even comes with an expressJS based testing suite and mocks server.
Once you are ready to incorporate it to your NodeJS, Flask, or whatever other application all static files should be available in the ember-cli dist directory.
Just don't forget to build the ember-cli project before porting via the means of ember build. After that it's just a simple matter of moving the files in the ember projects dist folder into wherever you need in your environment.
Just to embellish a bit: Ember-cli has a great work-flow for use while building your ember app. Try ember serve for a quick example. I mention this because it speaks to your question of how to incorporate this into your existing project (by project, I assume you may mean workflow). I typically will build ember projects purely using ember-cli and consider the back-end (usually a REST-API exposed via either Flask or NodeJS) a separate concern. When importing the app all I have to concern myself with is making sure my server serves the correct static dist files.
I would not recommend using the Ember App Kit (EAK) as it has been deprecated in favor of ember-cli. It really is.. much, much better.
Ok so I'm going to try to be more complete in this answer. Let's start with the isolated question - ember-cli or eak? Definitely Ember-Cli, but why?
EAK is officially heading for deprecation in favor of ember-cli.
Ember-cli produces more structured, cleaner, maintainable ember code.
Ember-cli integrates your entire ember-app workflow.
Managing all types of dependencies and assets is made simple via bower install --save and Brocfile.js edits. (See the ember-cli docus for explanation)
Now the more complicated part of the question. How do I integrate this with an existing workflow? I recently ran into this when building a webrtc-included ember app. It just so happened that this was my first real use of ember as well. So, not yet realizing the full potential of my new hammer I wrote the REST API, Backend ORM layer, the signalling service, the session cache, and built a complete CI workflow first. Then I was ready to build my ember app and ended up in your exact position.
To short circuit a long story - the lesson I learned was that I should treat my ember-cli app like a completely separate concern. What I mean here is - there's my backend (NodeJS, Apache, Nginx... whatever) and what I code here is built, tested and integrated separately. It normally even lives in its own git repository. It's a separate concern to my front end equation which typically would consist of several components itself. My I-Phone Native app would have its own workflow from build-to-test and integrate to my backend via a REST API. My Android native app another. My web app another. For all intents and purposes, in my workflow these are entirely separate workflows that only tie together when we start talking Continuous Integration.
There's a lot of arguments for why you'd want to do this. Most importantly - it scales.
The beauty of ember-cli is that it makes it fairly trivial to get a workflow for your ember app going and trivial to redeploy your app + workflow on a new box/instance. I would certainly recommend referring to the official ember-cli setup instructions but I'm going to include them here in case the URL goes bad one day:
No really, refer to the link my instructions will suck in comparison...
Deploying a new Ember App
Install NodeJS, NPM and Git (ember-cli will as a default load git going for you on new apps) on your system via sudo apt-get install nodejs and sudo apt-get install npm, sudo apt-get install git.
Note: On Ubuntu 14.04 and some other Debian systems use sudo apt-get install nodejs-legacy instead. If in doubt, use legacy. If you experience problems using the node command after install, it's definitely that you need to use nodejs-legacy. Don't bother trying to do the linking manually.
Install required node modules globally: sudo npm install -g ember-cli, sudo npm install -g bower, sudo npm install -g phantomjs
Create new ember-cli app: cd <Desired Directory>, ember new my-app-name
Now you can look at ember help to begin learning how to use ember-cli. Hint: The --dry-run flag is your friend. You'll notice that when you installed ember-cli all the scaffolding was taken care of for you. You'll see that you can add things with simple ember generate commands and they will not only create the required objects, but the test files as well. Best of all, using ember serve you can start scaffolding your app and via simple flags you can configure the test server to actually proxy and use your already-existing REST API (if you have one) or the expressJS mocks server to build a psuedo-API.
Integrating it with your larger workflow from here is a simple matter of configuring whatever tools you use (I use Jenkins and Ansible for this kind of stuff) to distribute the dist folder of ember-cli to where it should go to be served as static content (it is just a single page webapp in the end).
If you want to instead play with an existing ember-cli app that operates in an isolated workflow and already makes use of most of the goodies in order to get some familiarity - as I suspect you'll quickly realize how to fit this into whatever your current structure is - feel free to clone and play with this one here.
And so finally - to answer the more specific question of how this might fit into an existing directory structure, I would break this down into two categories. When we're talking src - I would have it in it's own "structure", separated at least by being in a separate sub-directory of its own. When we're talking built and deliverable I would include the contents of the /dist folder in whatever static web server directory you want to serve your ember app from.
EDIT: I Added some more detail - hopefully useful details below the line break. Let me know if you have more questions or if I can explain anything better.
I am facing a similar situation. I am planning to use EAK as a "prototyping tool" in a separate project folder. Then build the distribution directory from EAK using grunt dist and insert that into the assets folder of my main Node.js project.