https://netsuiteprofessionals.com logo
Join Slack
Powered by
I’m curious how folks organize their SDF configura...
# sdf
m
I’m curious how folks organize their SDF configuration projects. Do they include the configurations for the entire account in one big project and deploy when a new feature is complete or do you create a new project for each feature. I can see pros and cons to both strategies. Just trying to get some thoughts from the community.
m
I maintain "solutions" as separate projects
...use a project that includes everything in a system for backup and searching for dependencies, but not for deployment
e
I maintain one SDF project per "feature" or "solution", as Michal says.
👍 1
m
I like the combination of the “project per feature” and a master project that includes everything. I can actually build a CI/CD around updating the “master project” when new features are finalized.
What about custom modules? Are those written as a “feature” and therefore their own project? Considering they often contain functionality to be used across features.
Or maybe all custom modules should exist as a single project
I’m thinking this approach because we utilize a 
config.json
file to modify the 
require.js
behavior. Seperate modules would update the 
config.json
file but it would be self-contained to project.
e
Personally I have found it exceedingly rare that my custom modules are reused across projects, so I don't have a common pattern for the situation.
The only things that are typically reused across projects are third-party libs, and I don't put third-party libs under source control. I just add a 
<dependency>
for the project
in both the manifest and the package.json
m
so @erictgrubaugh, you all use webpack or something like that to do a 
js
build of those dependencies?
e
It's just me all by my lonesome, so I have a pretty simple workflow. I just use npm, nothing else. No CI/CD as I just don't have the need.
m
So I’m familiar with 
npm
but admittedly I’ve only used it once or twice. I’m under the impression that you need some sort of build process to deploy those packages with a project.
Or are you just uploading your modules folder directly to NS? How are you getting access within the SuiteScript file? 
require()
?
e
If it's a common third-party lib, it lives in 
/SuiteScripts/lib/
, and I'll just manually upload the minified version there (e.g. 
/SuiteScripts/lib/lodash.min.js
). Then my 
manifest.xml
has a 
dependency
on that file being there, my 
config.json
will alias the minified file (e.g. 
paths: { "lodash": "/SuiteScripts/lib/lodash.min.js" }
), and my scripts can pull it in via 
define(["lodash"], function (_) { ... });
Nothing too automated about it
m
oh this is awesome. so you have a 
package.json
file in the project as well. where are those dependencies being saved?
e
npm
gives you several options for dependencies. You can use some reasonably advanced bundling functionality if you need. I just add the libs as a normal dependency, which pops the file into my 
node_modules
directory, then I copy the file from there to the File Cabinet manually since I only need to do it one time. If I were building SuiteApps, then I'd just source control the libs I needed directly in the project.
c
Where did you find any documentation on the manifest.xml file, what it does and uses?
m
makes complete sense. I imagine you’re excluding the 
/node_modules
and the 
/SuiteScripts/lib
folders from source control.
e
Yes definitely
My projects are always in their own subdirectory of 
/SuiteScripts
as well
so if a client has any script files directly in 
/SuiteScripts/
, then they're not mine. I keep all projects contained in their own folder
As much as possible, I want everything required for one project to be in exactly one place.
m
gotcha. we are an internal team, so we just have a single customization folder under 
/SuitesScripts/
and then we have folders for each script type and the script lives under their respective type.
when we were on SS1.0 we named files but the “feature” they concerned. Moving to SS2.0 the file names are a combination of the Script and Script Deployment IDs
One last question @erictgrubaugh, how do you manually copy those third-party libraries that have their own dependencies.
How do you keep track.
And wouldn’t it require a modification of the primary library? How would it find it’s dependency in the 
SuiteScripts/lib
directory?
b
I do think a package manager and build process is needed to do this well, but I haven't seen any examples of this in the wild yet. Version management can become very frail over time without this in my experience...
It's something I'll be attempting to tackle in this project soon: https://gitlab.com/tolaeon/sdf-starter/-/tree/feature/test-sb-deploy
e
@Miquel Brazil I can't say I use any third-party libs with their own dependencies. 
moment
and 
lodash
are the only libs I use very consistently. Anything else would be much more project-specific and would be stored with that project directly.
I just haven't found the need for a significant build process. I don't know what problem it would solve for me. When I'm writing code, I'm a solo operator. When I advise my clients, it's very different when there is a team of people working on multiple clients or multiple SuiteApps or what have you.
2 Views
Open in Slack
PreviousNext
Powered by