Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template variable for file created date vs modified date? #20

Open
robross0606 opened this issue Feb 16, 2024 · 4 comments
Open

Template variable for file created date vs modified date? #20

robross0606 opened this issue Feb 16, 2024 · 4 comments

Comments

@robross0606
Copy link

robross0606 commented Feb 16, 2024

Our copyright notices need to be different based on when the file was originally created vs. modified. Examples:

/* Copyright (c) 2019, 2024; All Rights Reserved. */
/* Copyright (c) 2019 - 2024; All Rights Reserved. */
/* Copyright (c) 2024; All Rights Reserved. */

I see there's a template variable that exists for YEAR but that's the current date. Is there a way to obtain the original create date of the file? Is there a way to do conditionals if the created date doesn't match YEAR? Or, even more accurately, something like the earliest year from the git file commit.

@nickdeis
Copy link
Owner

Hey @robross0606 ,
Thanks for filing an issue that was so clearly defined.
I think your suggestion has a lot of merit to it, and I think it would save people from having to update copyright notices every year (it's allowable, but not always desirable to do so).
I'm going to do some research and look into some potential solutions.
Thank You,
Nick

@nickdeis
Copy link
Owner

Hey @robross0606,
So, git doesn't retain file creation dates. There is a way to get when the file was added to git:
git log --follow --format=%ad --date default {fileName} | tail -1.
This has some overhead, assumes a lot of things about the system, and I don't want to add this as a standard feature.
I do however want to make it possible, so I might introduce the concept of "functional variables/patterns"
Here's an example:

config/copyright.js

/**
 * Copyright (c) <%= YEAR_CREATED %>-<%= YEAR %>
 */

.eslintrc

{
    "notice/notice":["error",
        {
        templateFile:"config/copyright.js",
        templateVars:{YEAR_CREATED: async ({fullFilePath}) => {
            const {stdout} = await execp(`git log --follow --format=%ad --date default ${fullFilePath} | tail -1`);
            const date = new Date(stdout);
            return date.getFullYear();
        }},
        varRegexps:{YEAR_CREATED: async ({fullFilePath,templateVarValue}) => templateVarValue}
        }
    ]
}

Essentially, you can change the value based on the fullFilePath, and also change the pattern.
This will probably introduce significant overhead, but it's probably worth it in your situation.

Let me know what you think!

@robross0606
Copy link
Author

robross0606 commented Feb 20, 2024

The idea of being able to shim your own functions to feed variables seems like a great, flexible way to approach this. If you're interested specifically in an example of getting the git date span, check out https://github.com/shybyte/copyright-header.

As for overhead, we'll probably be running this specifically using lint-staged and a git hook, so the overhead will be limited to staged files.

@nickdeis
Copy link
Owner

nickdeis commented Mar 2, 2024

Hey @robross0606 ,
I had to take a very long look at that repo. It's truly quite awesome and I was rethinking things because of it. Then I got distract with some things in my life. Sorry about the delay.

I still think my idea might make the most sense? I think what I dislike the most about copyright-header is the fact that you can't configure your own template. Which, to be fair, was kind of a technical hurdle when I first made this so long ago.

Either way, I always offer the person who made the issue the ability to implement themselves before I try. I'm very generous with accepting MRs because I just want other people to understand this code.

If not, I will try to implement it in the next week or so.

Best,
Nick

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants