So, by now you should have heard the SharePoint Framework is now available within, as it hit GA the other week. This is a big milestone and one that we should all take note of now.
However, my experience has always been that for most organizations, no one is truly ready to utilize a new component, service or adopt a change when it launches. This is often because the effort needed to get everyone up to speed, is often outweighed by the current work that needs to be completed. As such we often find or ourselves becoming masters of searching the internet, trawling through Google or Bing results hoping that someone else has hit that issue of wrote a blog post about it. The good news though is that Microsoft have done a pretty decent job of documenting most things that you could face or need to know for the SharePoint Framework, however not everything is covered.
Now if we wanted to do create the same code using the second pattern which is CommonJS, we would need to change it slightly. If you have written any code for Node.js for example then you normally use this approach.
Lastly, we could write the code in Universal Module Definition (UMD) format. This is becoming more popular and if you look at some of the SharePoint Framework core code, it follows some of this pattern.
Each type works, each time performs the same task, but each one has its own merits. When coding for a SharePoint Framework web part, the pattern you will be following is for me personally a mix between using CommonJS and UMD syntax. As an example, including jQuery within a SharePoint Framework web part requires not only the references to the code, but also it will need to be specially includes in the web part code.
Notice that because these files are not written in the newer UMD format, that we must reference this in this way, setting the code name, path and global name that we then use within the import statements in the web part. If were adding a newly defined UMD module we could simply reference it this way:
As you can see this can make it very confusing when trying to convert existing code into SharePoint Framework ready code. Of course, we don’t really want to refactor all the code, but my suggestion would be to maybe look at that as part of the task, the same as you would do if you were converting a full trust SharePoint solution to this new framework. To help you in referencing external files correctly, the amazing guys of at Rencore just realized a tool that can be used, you can read more about it here: https://rencore.com/blog/correctly-reference-scripts-rencore-script-check/
The real goal here is to really think about the solutions you are making and probably refactor to make the solutions module based which will follow the pattern found in the core SharePoint Framework.
To help you understand how to refactor I would suggest some of the following resources and examples: