right now, I have a React-native project which I created with the vanilla CLI.
I just heard of expo, and I wanted to use it, but it seems I must create my project on it first.
is there a way to migrate a react-native-vanilla project to expo?
Yes, if you have exp installed, you can run exp convert in your project directory. Note that this process won't check whether you have any native modules in your project, and if you do you'll likely have some issues.
As of this writing, there's one notable bug in this process where it may leave your project with both an exp.json file and an app.json file, which need to be manually merged.
Related
I have been looking for a way to mostly share some code between projects specifically for SPFX and fluent ui. We found 3 main ways to do that.
1.
Creating a component library is the way that seemed least complicated cause it uses the same infrastructure and do all building without the need to configure it.
But this adds some issues, we need to built and manually link the solution locally to make it work, this will also work if we put in a repo. so this is mitigated.
The second is that implicitly this will also require the fluent ui and react. Plus having to place it inside a SPFX component library project.
2.
I saw some promise using paths in ts and this works fine while using the ts compiler. It will go to the folder that your proj is referring and build it at calling time. which is great. But it did not work in SPFX.
3.
Another way was to have a post install to sync the folders which seems easy enough but I wonder how practical this is plus how people are doing it, if they are, how.
All I wanted to figure out now is a way to take my component code and share as if they were in a folder of my src or a simple extension of the code. No need to have extra dependencies or build steps, just the code that can be used as a ts/tsx file. ex:
shared lib:
//assuming I have react and fluentui already installed for the project.
import button from 'fluentui';
export const fancyCustomButtom = (props) => {
return (<Button text="Standard" />);
};
src project folder:
import {fancyCustomButtom} from 'shared-lib'
It is fine if it needs to build the files before we can use it but can we do it at build time or when the package is installed? also wouldn't it increase my bundle size by making both module dependent on things already available (react, fluentui)?
Given the way Microsoft have architected the loading of bundles in SharePoint and Teams - I believe an SPFX component library is the best way to share code between different solutions, particularly if you are looking to minimise bundle size...
Imagine you have a library for something re-usable: a form, a set of standard branded components - something of that nature. You could put your shared code in repos and add references to it - either by publishing your own repo publicly or using the npm install git+https://yourUrl syntax; but what effectively happens there is that your code is pulled down in to node_modules for each project, and any referenced module code is included in your bundles. If you have two, three, four or more webparts on the same page - using those same libraries, you're multiplying how many times that code is included on the page.
If you follow Microsoft's guide on setting up a component library project however, your npm link commands allow your types to be recognised in consuming projects without needing to actually include the bundled distribution code. You can deploy your library code once to the App Catalog, and if it's referenced in other solutions -- it's loaded on pages as needed: once.
I have found the development experience to be quite flaky at times, but it does work. When I run gulp clean on my library code, or come back to it after some time, I sometimes find that I need to run npm link and npm link my-project-name again as per the instructions in the above tutorial. Whenever you run gulp build on your library, you should also rebuild the project that consumes the library, either by using gulp build / bundle or by saving a file (if you're running gulp serve). This process works well for developing, and once it comes time to deploy, all you need to do is add a named reference to your library inside package.json and then deploy both .sppkg files to your App Catalog.
In terms of your last question re: bundle size - react is not actually included in the dependencies for an SPFX library project, but you will find it's available to use. When you build your library, if you take a look in the generated javascript in your dist folder, you will see it's listed as one of the dependencies for the webpacked content along with react-dom and ControlStrings. It's on line 1.
office-ui-fabric-react is included as a devDependency thanks to the #microsoft/sp-webpart-workbench package that gets scaffolded with all SPFX projects - and if you check your library's dist javascript, you will see that included components are being webpacked and included in your bundle. I'm not entirely sure if when you pull this code in to your consuming project, whether webpack then tree-shakes to de-duplicate and ensures only necessary code is included: I don't know. Someone else may be able to illuminate us there or provide a more accurate explanation of what's going on... I will update this response if anyone comments to let me know.
And finally, this is more of a personal way of working, but it may be worth consideration:
When developing a library, I sometimes reference it in other projects via a local npm install ../filepath command. This ensures that when I install the library as described, the consuming project installs any necessary dependencies. I'm able to tweak both projects if I need o. When it comes time to deploy, I commit my changes to both projects, deploy my library code to the App Catalog, and then npm uninstall the library from the consuming project and add a reference as described in the above tutorial. When I deploy projects that use my library, they just work.
I recently developed a library that uses pnpjs, in particular the #pnp/sp library that is used to talk to SharePoint. If you look at the Getting Started guide for that library, they expect you to pass a reference to your Application Customizer or Web Part context during setup, or explicitly set things up using a base URL and so forth - and of course, a library doesn't really have a page context of any sort - the whole point of this code is that it's reusable. So that poses a challenge. My solution was to do the setup in the consuming web part(s) and ensure that they pass a reference to the sp object (which is of type SPRest) to any code or components that exist in my library. My library has peerDependencies on those pnp libraries so that the code isn't duplicated in consuming projects. Sometimes you have to think about what your library needs to include in its bundle and what you expect consuming solutions to already have, and maybe find ways to ensure things aren't included that aren't needed.
For example, in the scenario you talk about, you may want to ensure fluentui or office-ui-fabric-react are only devDependencies or peerDependencies for your library. As long as your library and the project(s) consuming your library both use the right version(s) you shouldn't have any trouble, and you can document any pre-requisites with your library documentation. You can check which versions of these libraries are installed per the SPFX version you are currently using ie. SPFX v1.11 or v1.12 etc. Just run npm ls <packagename> to get a breakdown, or check your package.json file.
All my VueJS projects use at the beginning the same baseline :
Vuex
Vue Router
Immutable.js
MathJS
MomentJs
ChartJS
Plus, all my projects have quite the same "index.js" file.
Is there a way to have a command line (preferably based on Vue CLI) that can generate a project with a pre-coded "index.js" file and a package.json with those above dependencies ?
It sounds like you are wanting to use the Vue CLI to create a project. However, you additionally want some default npm packages to be installed and imported into your index.js file.
Answer: no. this functionality does not exist (currently)
Some Suggestions:
Open a feature request here. If you did do a feature request, you should descibe it in a more general way. For example 'allow the ability to specify npm packages on project creation' opposed to specifically installing ChartJS, Moment and the other ones. That's too specific, that will get shot down and closed in a heart beat.
Create a repo with the project structure and packages you want and always start from that repo (opposed to using vue cli)
Write your own custom node cli to interface with vue cli that handels your extra steps for you. You could easily write a node (console program) that executes the steps you want. Basically, create the vue project, npm install what you need, generate an index.js with your package imports.
I think the easiest route is to just create an empty vue project how you want it. Save that repo as 'vue-boilerplate' or something and just always start off with that empty project opposed to doing vue create every time.
In my personal opinion, I think going through all this to npm install 3 packages and add the imports to a js file isn't entirely worth it unless you find yourself creating a massive amount of projects that will all require the exact same setup.
Angular has a similar idea called schematics but I do not see an equivilant within Vue as of yet.
I am trying to learn Electron (Atom-Shell) but I am finding it pretty tough to find documentation for it...
I am simply trying to figure out how to create a link with in index.html, and have it open a terminal window or run some sort of program.
I learn languages by learning specific tasks as I need them in a program, so that is why I am asking so then I can utilize the technique used in other ways in my programs.
Thank you for helping.
Well, essentially Electron is just a customised version of a Chromium browser that comes packaged with Nodejs and some really cool packages that basically allow you to run the custom browser as if it was a native platform application. Because of that creating an Electron app is very similar to creating a web-app that has a Nodejs back-end.
So to get started with a simple "Hello World!" app, you can just run the following npm...
npm install electron-prebuilt --save-dev
Once the npm is installed you'll need three files to run an Electron app.
A package.json file
A javascript file (default is main.js)
An html file (default is index.html)
See this GitHub repo for a quick copy/paste version of each and more detailed instructions: https://github.com/mafintosh/electron-prebuilt
after that you're ready to simply run your app...
$ electron .
Finally, one way to open a terminal window would be to use an onclick attribute in your html to trigger a child_process, found here, in a function.
That's it! You should be able to edit your html and javascript files as you would for any web-app, and take advantage of the added features that Electron provides.
I'd also check out these resources for more info:
A Quick Start intro to how Electron works -- https://github.com/atom/electron/blob/master/docs/tutorial/quick-start.md
The Atom discussion forum (Because Atom was built with Electron, and is made to be hackable, the community is quite active) -- https://discuss.atom.io/c/electron
A cool repo to keep up with the latest info. It includes links for apps that currently use Electron, tutorials, videos, and more --
https://github.com/sindresorhus/awesome-electron
I hope that helps!
I noticed that somehow there is no packages folder in my newly created Meteor 0.9 project. This means that it must be using package from the ~/.meteor things. However, I cannot work like this as I am hopping between machines all day and I would like the package to stay locally; like in the project folder itself.
In the previous Meteor 0.8.3 project, I manually created packages folder in the project and when I add package it went inside there (for example i can find collectionFs inside package/ in the project directory).
I want it to be like this. How can I do this safely?
You can still drop packages into the top-level "packages" directory inside your project and then run meteor add like usual. These packages are just treated as app-specific packages. Here are the docs about using packages. The relevant bit is quoted here:
In addition to the packages in the official Meteor release being used by your app, meteor list and meteor add also search the packages directory at the top of your app.
I think the idea was to delineate the stand-alone application code from 3rd party libraries. As a package author, this means there are less forks of my library with subtle changes floating around on Atmosphere. It also makes your apps a bit less prone to bugs (given the packages are stable), and encourages better package maintenance.
If you want to use local packages though, here is a good walk-through.
For NPM packages, also check out meteorhacks:npm | github
For the collectionFS, you have to use meteor 0.6 version.
You have to add new release file of meteor 0.6 version.
https://github.com/CollectionFS/Meteor-cfs-example-filemanager
I was looking over Typescript and was a bit confused about how you could build your js files from the ts files via the command line.
It implies in the documentation that you can do it easily through nodeJS, which would be great if I wanted a dependency on nodeJS... So is there any way to compile it via the command line without having nodeJS or visual studio?
This may seem crazy to some, but I would just put a build script step to output the javascript at the end if possible then package it into my release, as I tend to do most of my javascript development with RubyMine and don't want a dependency on nodeJS or Visual Studio for my build server.
If you install the TypeScript Tools without Visual Studio installed on the machine, tsc.exe and its dependencies will still get installed.
You can also just xcopy deploy tsc.exe (I don't have a definitive list of its dependencies, but it's pretty straightforward to figure out, or just copy everything that gets installed to the SDK folder) to a build server. The only thing unexpected you would need is msvcr110.dll, which you may or may not need to copy to tsc.exe's path.
The link in Ryan's answer is now heavily outdated and if you use it will generate a TS1005 error.
Here's what you want https://www.microsoft.com/en-us/download/details.aspx?id=55258 and it is still put in the same Program files x86 / Microsoft SDKs directory, and for me at least was not added to my path.